Sziasztok!
Egy sokkal erősebb gép közel 2x annyi idő alatt végzi el a MongoDB importálást, mint a jóval gyengébb és nem tudunk rájönni, hogy miért.
A teszteléshez ezt használtuk: https://github.com/jsteemann/BulkInsertBenchmark
Lokálisan futtatva: `php run.php`
Ami a stage szerveren 261,1 mp alatt lefut az a production-on csak 466,0 mp.
Vagy ami 9,2 alatt az 14,1 alatt.
A lekért MongoDB configból látszik, hogy a production szerveren a storageEngine {persistent} true-ra van állítva.
Azonban ha ezt módosítani akartuk az /etc/mongod.conf-ban (tudom YAML, tab nem lehet),
akkor 2-es kóddal elszáll a mongod main process, ami "The specified options are in error or are incompatible with other options."
Próbáltuk a loggolást teljesen kikapcsolni meg a diagnosztikai adatok gyűjtését, de az sem hozott eredményt.
Próbáltuk azt is, hogy mmapv1 helyett wiredTiger -re állítjuk a tárolást, de nem segített.
A production gép nem csinál ezen kívűl szinte semmit, mert nincs még publikálva az oldal.
Ha valakinek van bármi ötlete, hogy mit és hogyan próbáljunk ki, akkor kérjük írja meg.
A két gép configja:
1. production (fizikai gép)
- CPU 48 mag, bővebben: http://pastebin.com/74SbJnAp
- RAM 64GB
- Disk HDD
- RAID LSI Logic / Symbios Logic MegaRAID SAS 2108 [Liberator] (rev 05), bővebben: http://pastebin.com/9vYAg7jL
- Ubuntu 14.04.5 LTS
- Linux 4.4.0-57-generic
- Mongo version 3.2.11 mmapv1
- Mongo config etc http://pastebin.com/nB1zNwZS
- Mongo config dump http://pastebin.com/2hDCbrD9
2. stage (virtuális gép, KVM)
- CPU 2 mag, bővebben: http://pastebin.com/74DPCQ20
- RAM 4 GB
- DISK HDD
- Ubuntu 14.04.3 LTS
- Linux 3.19.0-78-generic
- Mongo version 3.2.1 mmapv1
- Mongo config etc http://pastebin.com/YdwTRP2h
- Mongo config dump http://pastebin.com/v1mP29Pr
Hozzászólások
"Disk HDD"
Milyen HDD milyen RAID-ban?
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
+1 erre is válaszolhatnál, kedves poszt-toló!
+1 (signup)
Elnézést kérek, sajnos közbejött pár fontos feladat, de amint lesz időm összeírom.
Ennyi információ alapján még tippem sincs. Ugyanakkor azért megnézném, hogy a mongo hogyan fut az egyik és a másik gépen (cpu/mem/io használat egyebek) hátha abból látni valamit.
Gondolom meg van ennek is az oka, de miért nem ugyanolyan OS fut a kettőn?
FathoM
A procik tipusa es orajele? A prod gep mast is csinal olyankor? A stage kernelt is 4.4-re updateeljetek.
CPU stage : http://pastebin.com/74DPCQ20
CPU production: http://pastebin.com/74SbJnAp
A gép nem csinál ezen kívül szinte semmit (smtp/imap), mert nincs még publikálva az oldal.
Ez nem a pontos CPU típus, az órajel mondjuk legalább kiderül. A stage gépen van egy 400MHz-es előny, bár ettől nem kéne kétszer gyorsabbnak lennie. Ami gyanús, hogy az első gépen ha sok NUMA node között ugrál a task ott viszont lehet veszteség.
Az a persistent=True az IN-MEMORY storage engint engedelyezi. Valoszinu hogy eleg sok adatot tol a memoriaba es kevesebb a disk I/O. Idovel aztan kiirja de gondolom a 64G-be eleg sok minden belefer es mongo egyebkent is szivesen elterpeszkedik es kihasznalja ami rendelkezesre all - plane ha kered is ra a konfigbol.
Shot in the dark, de amikor legutoljára ilyennel találkoztam (test rendszeren korrekt sebesség, éles rendszeren több nagyságrenddel lassabb, miközben a HW messze elég kellett volna, hogy legyen), egy haveged telepítés oldotta meg; gyakorlatilag állandóan üres volt az entropy pool és arra várt a rendszer.
Egy cat /proc/sys/kernel/random/entropy_avail -t megér.
BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)
Ez pont akarmi lehet. A mongot nem ismerem de nem jo az eltero rendszer a dev es prod kozott de az itt egy update szerencse.
A verziok elterese mellett a numa lehet baj vagy, vagyis minden cpu var a masik altal kezelt memoriaraban levo adatra.
Köszi az ötletet, észben tartom...
Szerkesztés: közben megneztem sok helyen írják hogy vcpu-bol sok a 16 is egy virtuális gepbe. Ma is tanultam valamit...
miert lenne sok? persze ha a fizikaiban van 4, akkor sok :)
nekunk 28 magosak a legnagyobb VMeink, ez elfer egy numa zonaban (2x14 mag + HT van alul), igy nincs veluk semmi problema. csak a NUMA-t eszben kell tartani.
hdparm -tT ?
Iostat ?
Htop/stop valami piros?
Mekkora a db? Simán befér a kis gép memoriajaba is?
Esetleg ki lehetne próbálni, hogy ha 47 magot letiltasz, akkor gyorsabb lesz-e, vagy lasabb.
elsővilágbéli gondok
:D :D
----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám
regen wotnal mukodott! :p
--
NetBSD - Simplicity is prerequisite for reliability
A production gépben lehetőleg RAID5-ben vannak a diszkek?
--
Gábriel Ákos
http://ixenit.com
2017ben remelhetoleg SSD-n van minden, es elfelejtjuk mar a szar HDD-ket meg a RAID5-ot
Hah, most mondjam azt, hogy egy atlagos, n3.nhs.uk datacenterben evi 60 GB HDD (!) tarhelyet hozzacsapni egy virtualis gephez 1500 dollar? SSD-bol meg negyszer ennyi?
Tragikomedia.
----------------------
while (!sleep) sheep++;
az gondolom valami SAN storagerol jon, nem local HDD-rol beszelunk, nem?
De. Ettol fuggetlenul elkepeszto.
----------------------
while (!sleep) sheep++;
Az a nettó 60GiB az datastore-t tekintve nagyjából 70, ha raid1, akkor 140, ha meg replikálva van egy másik DC-be, akkor 280... És a SAN-okba való diszkek nem az olcsóságukról híresek, ráadásul ha jó iops-ot akarsz tengelyes diszkekkel, akkor sok, relative kisebb diszket pakolsz a motyó alá - ami sok fiók (az sem két fillér, bár a betolható diszkek kapacitását és árát tekintve nem vészes - kivéve, ha kevés üf. miatt kell polcokat venni...)
SSD-vel annyiban jobb a helyzet, hogy ott nem elég kevesebb meghajtó, és azt sem muszáj raid1 jelleggel összepakolni.
Ebbol is latszik, hogy nem csak Magyarorszagon elnek meg sokan es jol a kozbeszerzesekbol :)
actual fuck - the comment
Remelhetoleg nagyon nem :)
Egyszer elofordult, hogy brand gepen (ugy emlekzsem HP volt) a disk vezerlo ujabb firmware kb tizszeresere lassitotta a dolgokat. Firmware downgrade aztan megoldotta.
Szerintem nezzetek meg a firmwareket is a ketfajta gepen.
Egyelőre nekem még az sem világos hogy fizikai vagy virtuális gépről beszélünk :)
+1 én is csak tapogatózom
Szerk: közben megláttam. Régi egy VM, az új egy fizikai vas.
Helyben futtatod a tesztet vagy halozaton keresztul?
--
http://blog.htmm.hu/
mindegy
Ezek mégis milyen "gépek" ?! (közben jól értelmezem, ezek 4 socket -es gépek, egyenként 6 maggal) mármint a production gép... mert akkor az nem 48 mag, az csak 48 szál - HT ráadásul ezek eléggé öreg CPU -k
Sokat segitene kideriteni a problema okat, ha futna a sar a gepen egy import soran aztan ideposztolnad a linket
sadf -- -A -p | nc graph.sanxiago.com 443
Mongo kepes bizonyos muveleteknel 1 magot enni, ott szimplan az szamit, hogy 1 magja turbo boosttal mennyit szamol. Ezert van az, hogy nalunk gagyi 4 magos 3.4ghz e3/e5 a leggyorasabb mongo alatt.
Masik, hogy aza "Timing buffered disk reads: 368 MB in 3.01 seconds = 122.19 MB/sec" nagyon keves. Nem derul ki, hogy van-e write cache a kartyan, es engedve van-e, read az biztosan nagyon karcsu, olvasast a 64giga ram biztosan segiti, de ha kartya nincsen 2 giga flash/battery cache, akkor tetu lesz az irasod (olvasasi sebessegbol kiindulva).
Csak egy osszehasonlitasert, nalunk 8x144GB 15K sas vinyo, ami 2009ben vettunk, es hozzatartozo raid kartya, raid10-ben 700-800MB/sec produkal. Tegyel ala par ssd-t, es fenyevekkel gyorsabb lesz.
Teszt pedig insert, ami 1 magot fog terhelni, es irni fog a storage rendszerre. Hiaba van akarhany magod, es akarhany giga ramod.
Ha igazad van, és valoban egy magot használ, meg ha nekem is igazam van akkor:
a dev server BogoMIPS-je 4788, amig az éles 3989, meg orajelben is van különbség. Tehát egy magra nézve a dev erősebb. de fixme
------------------------
Jézus reset téged
^^ egy igazi szakerto!
Igen?
------------------------
Jézus reset téged
BogoMips semmit nem jelent, meg az órajel se (kivéve ha azonos magok)
bogomips ezen a platformon cpu mhz szamanak duplaja. Ha igazad lenne, akkor 3ghz p4 gyorsabb mint egy mai 6 magos 2.4ghzs i7.
Gyerekedet ha van vagy lesz ne igy neveld :d
------------------------
Jézus reset téged
marmint, hogy ne legyen hulye? bocs, de szerintem ez alap elofeltetel.
marmint, hogy ne legyen hulye? bocs, de szerintem ez alap elofeltetel.
Ja meg remek motivacios kartyak.
------------------------
Jézus reset téged
szemelyes failt szeretnel megosztani velunk?
Van ra igeny? :D
------------------------
Jézus reset téged
Mellesleg nem feltetelezem hogy sok spec matek kell egy inzerthez ergo marad az orajel.... Meg az io.
------------------------
Jézus reset téged
Journaling paramétereket nézd meg. Az nagyban tudja az insert sebességet befolyásolni.
Mindenféle hozzá-nem-értés ellenére az elsö megérzés, hogy kb. nincs többszálú végrehajtásra optimalizálva a kód, így a sok CPU mag gyakorlatilag kihasználatlan.
--
robyboy
Tudni kellene, hogy a stage alatt milyen diszk infrastruktura van. Igy eleg nehez osszevetni a kettot.
Azt is tudni kellene, hogy a "DISK HDD" az mit takar egyik illetve masik esetben. Egy RAID 5 gyorsabb is lehet irasban, egy regi SCSI disk lassabb tud lenni, mint egy SAS diszk, raadasul az se mindegy, hogy a production rendszer alatt nem-e valami write cache-sel megtamogatott RAID megoldas van, mig a virtualis gep alatt esetlegesen csak egy nyers RAID van.
Annyi sok minden lehet, hogy ennyibol eleg nehez tippelni. Merj disk IO-t mind a ket gep esetben, hogy lasd, nem az I/O -d keves-e.
--
Blog | @hron84
Üzemeltető macik