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(a)gmail.com>om>: > >> 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(a)lists.vpsfree.cz >> To unsubscribe send an email to community-list-leave(a)lists.vpsfree.cz > _______________________________________________ > Community-list mailing list -- community-list(a)lists.vpsfree.cz > To unsubscribe send an email to community-list-leave(a)lists.vpsfree.cz