Очень хорошо организован и описан процесс, респект.
Можете поделиться заданиями для скриптов тестирования и дампом тестового сайта? Мы сейчас собираемся прогнать нормальные нагрузочные тесты Битрикса на нашей платформе, и было бы интересно сравнить на одинаковой задаче. Особенно интересно оценить работу композитного кэша.
Да, это самый простой способ. А если atime отсутствует, то есть strace и ftrace/trace-cmd, DTrace, SystemTap. Но тут автор не ищет легких путей :)
Хотя главная ошибка, что он ловит только open, а нужено еще и отслеживать stat, т.к. часто бывает проверки наличие файлов/каталогов, без того, чтобы открывать их.
Но замедление бэкапа приводит и к тому, что объем изменений в снэпшоте будет намного больше, чем при быстром бэкапе. Из-за этого увеличится время, требуемое на слияние снэпшота после бэкапа и, следовательно, увеличивается вероятность того, что кластер развалится тогда. Или нет?
Второй подход — не так уж хорош, чтобы на него смотреть :) Вот третий — да, хорош всем, но он существенно сложнее в реализации. Особенно если диски хранятся в отдельных файлах.
Сейчас зашел на build.com и вижу у них большие полноцветные иконки-фотки. Вероятно, они не ограничились удивлением тому, что плоские монохромные иконки дали плохой результат, а стали проверять, почему результат оказался противоположным ожидаемому. Ну и нашли.
Отсюда мораль — если в результате тестирования вы получили результат, противоположный ожидаемому, стоит поискать ошибку в реализации желаемого решения.
Забавно, а ведь и правда. Описать задачу тестами — то же самое, что и рассказать кому-то другому о том, как она работает. Правда, для этого лучше не мелкие юнит-тесты, а покрупнее, спецификации рабочего процесса.
Наверное, это не столько обратная связь, сколько отсеивание при объяснении или тестировании важных вещей от второстепенной шелухи.
Не путайте stable с snapshot. Вам правильно советуют — stable как раз является тем, что правильно и нужно использовать в работе. А не застывать на релизе и держаться за него до следующего релиза.
Но к релизам x.0 всегда нужно относиться с осторожностью, все верно.
Одно дело прочитать, другое дело продумать и укрепить в глубине памяти :)
В опросе еще одного пункта не хватает, который для такой статьи может быть применителен чаще всего: прочитал, в общих чертах прояснил для себя как эти драконы размножаются; в том, что все понял, поручиться не смогу, т.к. чтобы все понять, нужно самому вдумчиво проследить и промоделировать все выводы, что требует много времени. Поэтому видя общую логичность предпосылок и результатов, доверяем автору без дотошного повторения его выводов.
Это не TLDR, но это отличная справочная статья, чтобы ее прочитать в общих чертах и при случае возвращаться для уточнения деталей.
А потом пользователь сам может определять правила старта процессов через юниты: ~/.config/systemd/user/
wiki.archlinux.org/index.php/Systemd/User#Automatic_start-up_of_systemd_user_instances
Можете поделиться заданиями для скриптов тестирования и дампом тестового сайта? Мы сейчас собираемся прогнать нормальные нагрузочные тесты Битрикса на нашей платформе, и было бы интересно сравнить на одинаковой задаче. Особенно интересно оценить работу композитного кэша.
Хотя главная ошибка, что он ловит только open, а нужено еще и отслеживать stat, т.к. часто бывает проверки наличие файлов/каталогов, без того, чтобы открывать их.
Отсюда мораль — если в результате тестирования вы получили результат, противоположный ожидаемому, стоит поискать ошибку в реализации желаемого решения.
Наверное, это не столько обратная связь, сколько отсеивание при объяснении или тестировании важных вещей от второстепенной шелухи.
Но к релизам x.0 всегда нужно относиться с осторожностью, все верно.
В опросе еще одного пункта не хватает, который для такой статьи может быть применителен чаще всего: прочитал, в общих чертах прояснил для себя как эти драконы размножаются; в том, что все понял, поручиться не смогу, т.к. чтобы все понять, нужно самому вдумчиво проследить и промоделировать все выводы, что требует много времени. Поэтому видя общую логичность предпосылок и результатов, доверяем автору без дотошного повторения его выводов.
Это не TLDR, но это отличная справочная статья, чтобы ее прочитать в общих чертах и при случае возвращаться для уточнения деталей.