Ahoj,
tak to by mne docela zajimalo, myslim, ze problem bude nekde jinde :)
Anekdoticky podobne relevantni tvrzeni: ja pozoruju jenom zrychleni, ale nikde na nic zrovna konkretne sqlite nepotrebuju :D zrovna pri tech aktualizacich si toho zrychleni vsimnu nejvic :) Pro drtivou vetsinu bezicich virtualu jeste presun na vpsAdminOS znamenal presun z rotacaku na SSDcka.
Ze bude spatne napsana aplikace mit se ZFS horsi vykon, mne vcelku neprekvapuje taktez - obzvlast, kdyz nepocita s potrebou predchazeni read-modify-write, jak pise Glux - cehoz je sqlite zrovna asi jeden z nejlepsich prikladu, co vubec jde najit :D
Jeste, kdyz se to pri kazdem tom RMW cyklu znova dekomprimuje a komprimuje... konstruktivne muzu poradit akorat udelat tomu sqlite separatni dataset, kteremu se vypne komprese a nastavi se velikost recordsize tak, sedela s page_size u sqlite (v nasem setupu bych videl jako optimalni sweet spot neco mezi 16 a 64 kB). Tohle plati pro jakoukoliv databazoidni aplikaci, od ktere je potreba vykon - hodit na zvlastni dataset, vypnout kompresi a naladit velikost bloku proti sobe spravne.
Jinak ma totiz ZFS dynamickou velikost bloku a pokud se zapise tech dat najednou vic, tak skonci az 128 kB v jednom bloku spolu a tohle se pak bude vzdycky prepisovat cele, i kdyz se v tom zmeni jeden jediny bajt.
Pro obecny use-case dava v nasem pripade smysl mit defaulty takto, benefity checksumu, komprese a dynamicke veikosti bloku hodne prevysuji vyhody storage natuneneho na perfektni latenci pri jednom threadu, ktery dela neoptimalni IO pattern. Zmenit/ovlivnit si to pro svoje data muze kazdy, tyhle properties jsou vystavene pres vpsAdmin. Doporucuju pro takova specificka data udelat separatni dataset, at muze mit ta nastaveni jenom on. Jedine, co nejde u ZFS vypnout, jsou checksumy a copy on write (ale presne kvuli tomu ZFS pouzivame :D)
/snajpa
On 2023-03-03 18:00, Petr Vanek wrote:
Caues. Já mám dost mizerný write od migrace na nový AdminOS nebo jak se to jmenuje. Ale ještě jsem nenašel čas na analýzu.
Objevil jsem to při manuálních aktualizacích.
Petr
Mar 3, 2023 17:53:25 Josef Moudrik j.moudrik@gmail.com:
Ahoj,
ladim spatny vykon zapisu do sqlite databaze v produkci (jak je to dobre rozhodnuti nechme na jinou debatu :-D ); zapisy se deji v jednom threadu. Problem je v tom, ze transakce v produkci jsou 10-20krat pomalejsi nez u me na localhostu. Snazim se zjistit cim to je (driv nez budu muset migrovat na jinou db).
Nesetkal jste se nekdo s necim podobnym? Nejake napady?
Zkousel jsem zreplikovat chovani pomoci jednoducheho (serioveho) skriptu s 500 commity: https://pastebin.com/huhhVGw2
vysledky: Journal (write ahead log) x synchronous mode (off nejrychlejsi, normal bezpecnejsi & pomalejsi), cisla jsou mean +- std vteriny.
localhost (ssd v notebooku) journal= sync=OFF 1.051 +- 0.042 journal= sync=NORMAL 2.502 +- 0.237 journal=WAL sync=OFF 1.042 +- 0.022 journal=WAL sync=NORMAL 1.135 +- 0.065
produkcni stroj @ node21.prg journal= sync=OFF 2.778 +- 1.415 journal= sync=NORMAL 2.876 +- 0.627 journal=WAL sync=OFF 2.382 +- 0.404 journal=WAL sync=NORMAL 2.475 +- 0.494
Prijde mi zvlastni maly rozdil mezi jednotlivymi rezimy ve vps & to ze vse je o hodne pomalejsi nez nevirtualizovany stroj, myslite, ze to vznika nejakou vps abstrakci nad ssd?
Nejake napady co s tim?
Diky, JM _______________________________________________ Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz
Community-list mailing list -- community-list@lists.vpsfree.cz To unsubscribe send an email to community-list-leave@lists.vpsfree.cz