[Virtualbox + Ansible/Vagrant] Trage deploy performance

[TD-er]

Ik ben hier bezig met wat test-omgevingen en we werken met een team aan dezelfde Ansible/Vagrant deploy voor die test-omgeving.
Die omgevingen zijn nogal aan verandering onderhevig, dus moet je met enige regelmaat een vagrant destroy doen gevolgd door een vagrant up.

Op de Mac van een van mijn collega's gaat die deploy in net onder de 7 minuten, terwijl mijn laptop met Ubuntu 16.04 er pak 'm beet 3 kwartier over doet.
We zitten hier op een locatie met voldoende snel internet, dus dat is zeker niet de bottleneck.
En het is dus ook precies dezelfde deploy, met meerdere VM's, die elk dezelfde versie van Ubuntu/CentOS draaien.

De Mac en de laptop met Ubuntu hebben vergelijkbare specs. Beide een i5 CPU, SSD en 8-12 GB RAM (Ubuntu 12GB, Mac 8GB)

Wat ik al wel gemerkt heb, is dat wanneer je tijdens een deploy op de te deployen VM inlogt en bijv. een wget start van een redelijke omvang (500 MB), dat de deploy erdoor versnelt.
Dat deed mij denken aan kijken naar de CPU-frequentie en die bleef laag. Dus heb ik de CPU-governor aangepast en die staat nu op "performance", waardoor 'ie dus altijd op 2.8 GHz draait, ipv. 400 - 2800 MHz. Dat scheelt al iets en de deploy duurt nu tussen de 20 en 50 minuten (draait nu nog steeds, gestart om 10 uur)
Wat zo opmerkelijk is, is dat 'ie een aanzienlijk stuk sneller gaat wanneer je de betreffende VM iets actiefs laat doen en dat hoeft niet eens zoveel te zijn. Een htop draaien is al voldoende.


Heeft iemand nog een idee wat er aan Virtualbox veranderd zou kunnen worden, zodat dit sneller loopt?
Dit is namelijk onwerkbaar traag.
De meeste informatie over trage Virtualbox die online te vinden is, gaat over grafische weergave, maar dit draait dus headless.

Edit:

• Dingen die ik al nagelopen heb:
• VT staat aan, naast alle andere virtualisatie-gerelateerde CPU-settings in de UEFI/BIOS.
• TRIM op de SSD is ook al handmatig uitgevoerd, naast dat 'ie periodiek gedaan wordt.
• SSD haalt schrijfsnelheden tot zo'n 500 MB/s
• SSD heeft zo'n 130 GB vrije ruimte
• Geen actief gebruik van swap (ook niet op de VM's), geheugengebruik zit rond de 7 GB, de rest gevuld met buffers/cache.

[ Voor 12% gewijzigd door TD-er op 18-05-2017 10:59 ]

[Heli0s]

Je zou nog kunnen kijken naar de versie van Vagrent / Virtualbox. Er zijn een aantal versies die niet lekker samen werken. Ik heb met Virtualbox ook problemen gehad kwa disk performance. Toen niet de vinger op kunnen leggen, maar het schrijven van / naar de shared folder was mega traag. Volgens mij was toen een versie update de oplossing.

[TD-er]

Die gedachte had ik ook zonet gehad en na flink wat update-problemen heb ik in elk geval weer een werkende versie met de laatste update van Virtualbox (5.1.22-115126~Ubuntu~xenial) en Vagrant (1.9.5).

Echter sneller is 'ie niet. (real 49m3.175s)
Ik ga zo ook nog even proberen of het volgende toevoegen aan de juiste sectie in de Vagrantfile een oplossing is:

code:

                vb.customize ['modifyvm', :id, '--paravirtprovider', 'kvm']

Als ik Vitualbox namelijk gewoon opstart en dan de images bekijk, dan lijkt 'ie op "legacy" te staan.

[Michidez]

Heb je toevallig nog een toestel waar je mee kan testen? Dan kan je de oorzaak mogelijk net iets duidelijker aanwijzen.

[TD-er]

Michidez schreef op donderdag 18 mei 2017 @ 15:32:
Heb je toevallig nog een toestel waar je mee kan testen? Dan kan je de oorzaak mogelijk net iets duidelijker aanwijzen.

Je bedoelt op een andere computer?
Ik kan dinsdag even kijken hoe snel 't gaat op een Xeon-machine.
De anderen in 't team hebben Mac's en Windows, dus dat is een lastige vergelijking.

[jbhc]

Je hebt wel een VM met meerdere cores aangemaakt?

[TD-er]

jbhc schreef op donderdag 18 mei 2017 @ 18:46:
Je hebt wel een VM met meerdere cores aangemaakt?

Nee, ik heb 4 VMs draaien, elk met een core per VM.
Maar op vergelijkbare hardware -in een Macbook- gaat het 6 a 7x sneller om te deployen. Exact dezelfde configuratie per VM.