sokkal erősebb gép (48mag, 64GBram), mégis majdnem 2x lassabb rajta a MongoDB

 ( rascy | 2017. február 14., kedd - 17:35 )

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)

2. stage (virtuális gép, KVM)

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

"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