Artur Jamro added a comment - 2017-03-29 18:06 Related changes: https://gerrit.sio2project.mimuw.edu.pl/#/c/2723/ https://gerrit.sio2project.mimuw.edu.pl/#/c/2724/ https://gerrit.sio2project.mimuw.edu.pl/#/c/2725/ (with note: add db.sync() after changes in database). Test results: To co jest teraz, 256 pingów z envem: - poszło o: 2017-03-27 13:46:24.636091 - trwało do: 27/Mar/2017:13:47:25 +0200 - było to zachowanie, że najpierw wszystkie wysłał, potem wszystkie odebrał i dopiero potem zwracał je do sio - z jakiegoś powodu on z tego zrobił grupę?? To co jest teraz, 1024 pingów z envem: - od 2017-03-27 13:49:31.116649 - do 27/Mar/2017:13:53:37 +020 - bardzo wolne wysyłanie (na początku) - zużywa dużo dysku, mało procesora - iftop nie pokazuje jakiegoś super dużego ruchu (poniżej 1mb) Python dict, 1024 pingów: - od 2017-03-27 13:57:26.401480 - do 27/Mar/2017:13:57:30 +0200 - nie ma tego efektu z opóźnionym zwracaniem (xd, wtf) Python dict, 4096 pingów: - od 2017-03-27 13:58:45.188083 - do 27/Mar/2017:13:59:03 +0200 - pojawia się duże zużycie cpu - jest używany więcej niż jeden worker BSDDB, 256 pingów: - od 2017-03-27 14:02:21.931452 - do 27/Mar/2017:14:02:23 +0200 - sioworkersd.db powstało - niestety to był run bez disc-synca BSDDB, 256 pingów, z synciem: - od 2017-03-27 14:08:20.803634 - do 27/Mar/2017:14:08:29 +0200 - tym razem baza danych powstała BSDDB, 1024 pingi, z synciem: - od 2017-03-27 14:09:53.111766 - do 27/Mar/2017:14:10:31 +0200 - tak jakby robiły się bardziej na bieżąco BSDDB, 4096 pingów, z synciem: - od 2017-03-27 14:11:55.774867 - do 27/Mar/2017:14:14:39 +0200 - ciągle, tak jakby robil się synchronicznie - zużywa 2 workery xd - małe cpu, też duże zużycie dysku BSDDB, 2 x 2048, z synciem: - od 2017-03-27 14:15:55.288522 - do 27/Mar/2017:14:19:01 +0200 - działa - nawet czasem idą 4 workery (xd)