Припоминаю (видимо) аналогичный случай с нашей "полковой кобылой": ~10 лет назад (до докера) была своя мини-ферма для CI, где сборочные chroot-ы подтягивались/синхронизировались rsync-ом. И вот rsync иногда действительно подвешивался, то только при работе на серверах самой фермы (10G на локальном свиче). На рабочих станциях (с 1G) воспроизвести не смогли, поэтому грешили на сферу и/или свичи...
Milo Yip давно забросил этот проект, не принимает pull-requestы, но и не передаёт его.
Поэтому pull-requestы лучше сюда, а автор сможет там найти не только бенчмарк и конкурентов, но и тесты.
Это бэкап гитлаба. Он делается очень просто. В tar засовывает все репозитории и слепок базы и жмет gzip.
Это стандартная багофича большинства java-приложений с таким функционалом. Если не лень, то закиньте им багрепорт (целевой файл для tar нужно открывать с опцией O_DSYNC).
При этом, весьма вероятно, что у вас слишком большое значение vm.pagecache (процент памяти под кэширование) для ваших сценариев использования gitlab с учетом бэкапа. Поэтому за время бэкапа в кэш/память честно засасывается максимум читаемых tar-ом файлов, что выталкивает из памяти все холодные страницы.
У меня делается бекап по расписанию. Дисковый кэш выталкивает в своп все приложения на серваке.
Что-то не так у вас с этим ночным бэкапом.
Чуть менее чем весь приличный софт для бэкапа читает (и тем более пишет) данные не загрязняя pagecache: используется O_DIRECT и/или O_DSYNC для open(), posix_fadvise(POSIX_FADV_DONTNEED) перед close() и т.п.
Если с упомянутым выше какие-то проблемы, либо используются какие-то собственные скрипты, то достаточно на время бэкапа подкручивать настройки /proc/sys/vm. Лучше посредством sysctl, например так:
vm.vfs_cache_pressure = 222
vm.dirty_background_ratio = 3
vm.dirty_ratio = 7
vm.dirty_writeback_centisecs = 1
vm.dirty_expire_centisecs = 10
vm.pagecache = 1
vm.swappiness = 0
Соответственно, после завершения бэкапа вернуть исходные параметры (значение которых возможно тоже стоит продумать). Описание параметров легко гуглиться, вплоть до статей на Хабре.
Если проблема сохраниться, то я подумаю о том чтобы съесть свою шляпу.
Справедливости ради, именно для exec использование fork — весьма кривой оверкилл (если мне надо дёрнуть внешнюю тулзу из своей мегапроги, зачем для этого делать битовую копию памяти моего процесса? чтобы что?). Так что это скорее в unix-е не осилили нормальный CreateProcess.
Я правильно понимаю что вы не знаете о brk() и не в курсе ~40-летних рекомендаций по поводу его использования перед fork() + exec() ?
Спасибо за статью!
C "Эльбрусами" (5-го и 6-го поколений) и "Байкалами" планируете что-нибудь?
Санкции США это ачивка — значит делаем что-то существенное и нужное для своей страны, imho.
Ждем санкций против Microsoft за сотрудничество с ФСБ, ГРУ и далее по списку ;)
"Таланты из MIPS" уже трижды про… ли все полимеры (в MIPS, в Imagination, в Wave) теперь собираются еще раз освоить инвестиции под хайп от RISC-V.
https://caiorss.github.io/C-Cpp-Notes/resources-executable.html
del
Припоминаю (видимо) аналогичный случай с нашей "полковой кобылой": ~10 лет назад (до докера) была своя мини-ферма для CI, где сборочные chroot-ы подтягивались/синхронизировались rsync-ом. И вот rsync иногда действительно подвешивался, то только при работе на серверах самой фермы (10G на локальном свиче). На рабочих станциях (с 1G) воспроизвести не смогли, поэтому грешили на сферу и/или свичи...
Неосиляторный бедлам
Ерунда какая-то. Как-будто у автора попаболь, от того что его не оценили и куда-то не взяли.
два пузыря на поверхности о$новного
Milo Yip давно забросил этот проект, не принимает pull-requestы, но и не передаёт его.
Поэтому pull-requestы лучше сюда, а автор сможет там найти не только бенчмарк и конкурентов, но и тесты.
О как хорошо Bellingcat хомячкам зашел, прям рвут и мечут икру ;)
Никаких проблем, отличная беллетристика.
Ок, сейчас займёмся ;)
Ну какие-нибудь Скрипали "засвидетельствуют" или Bellingcat проведет очередное "расследование", и будет достаточно.
Это стандартная багофича большинства java-приложений с таким функционалом. Если не лень, то закиньте им багрепорт (целевой файл для tar нужно открывать с опцией
O_DSYNC).При этом, весьма вероятно, что у вас слишком большое значение
vm.pagecache(процент памяти под кэширование) для ваших сценариев использования gitlab с учетом бэкапа. Поэтому за время бэкапа в кэш/память честно засасывается максимум читаемых tar-ом файлов, что выталкивает из памяти все холодные страницы.Ну тут товарищам выше нужно определиться что они пытаются обругать:
brk()+fork()+exec().posix_spawn().clone()и тот-жеposix_spawn()как обертка надclone(CLONE_VFORK)+exec().;)
Что-то не так у вас с этим ночным бэкапом.
Чуть менее чем весь приличный софт для бэкапа читает (и тем более пишет) данные не загрязняя pagecache: используется
O_DIRECTи/илиO_DSYNCдляopen(),posix_fadvise(POSIX_FADV_DONTNEED)передclose()и т.п.Если с упомянутым выше какие-то проблемы, либо используются какие-то собственные скрипты, то достаточно на время бэкапа подкручивать настройки
/proc/sys/vm. Лучше посредствомsysctl, например так:Соответственно, после завершения бэкапа вернуть исходные параметры (значение которых возможно тоже стоит продумать). Описание параметров легко гуглиться, вплоть до статей на Хабре.
Если проблема сохраниться, то я подумаю о том чтобы съесть свою шляпу.
Я правильно понимаю что вы не знаете о
brk()и не в курсе ~40-летних рекомендаций по поводу его использования передfork() + exec()?Справедливости ради, лучше знать тему, а не рекламировать свою некомпетентность.
В особенности назначение и подробности обработки ядром флажка
CLONE_VFORK, которому уже более 20 лет.