PS. у нас row-based replication лет 7 работает, десятки RENAME TABLE каждый день, проблемы только если в RENAME указана нереплицируемая таблица (явный запрет в replicate_*) — но это человеческий фактор
Наткнулся на баг связанный со сбоем на loopback (как предполагаю): https://bugs.openvz.org/browse/OVZ-6684
Суть в том, что в какой-то момент перестает работать tcp на 127.0.0.1, а пинги ходят без проблем. Проявлялось на нескольких разных машинах, рестарт контейнера не помогал.
php сильно зависит от расширений и для длительного выполнения нужно аккуратно подходить к их выбору
по моему опыту: были задачи, когда mod_php мог обрабатывать до перезапуска тысячи запросов, а были и такие, когда приходилось передергивать через каждый десяток. причин я сильно не искал, но вот используемый во втором случае apc был зело крив и глючен.
imagick, например, также сильно зависит от библиотек и недавно мы поимели неприятную проблему с апгрейдом ImageMagick из-за старой версии lcms
>прекратит нормальное функционирование до тех пор, пока не будет перезапущен по какой-либо причине (например, по достижении max-requests)
Значит ли это, что пока не наберется max-requests, вассал будет возвращать ошибку на любые запросы?
спасибо, это уже интересное добавление к обзору :)
>NoSQL — очевидно, сеонизаторский прием.
Это вы про HandlerSocket? По-моему, довольно классная штука — очень красиво оптимизировали узкую задачу — выборку по PK.
>Обычно людей, перешедших с SVN, в командной строке страшит относительно сложное добавление отдельных файлов и коммит части изменений. В отличии от SVN (и других централизованных систем), где это — достаточно частая операция, в git и mercurial мне это не приходилось делать вообще (в основном, благодаря легкому созданию бранчей)
а можно мысль развить — почему их это пугает? и при чем тут бранчи?
в git как раз специально разделили процесс коммита файлов на 2 этапа — сначала формируется список изменений для следующего коммита, а потому уже они коммитятся. ключ -a сделан лишь для тех случаев, когда все изменения идут в один коммит (удобство)
откройте для себя git add -i — из всех изменений даже одного файла можно сформировать несколько отдельных коммитов
bugs.php.net/search.php?search_for=segfault&boolean=0&limit=30&order_by=&direction=DESC&cmd=display&status=All&bug_type=All&project=All&php_os=&phpver=&cve_id=&assign=&author_email=&bug_age=0&bug_updated=0&commented_by=
PS. у нас row-based replication лет 7 работает, десятки RENAME TABLE каждый день, проблемы только если в RENAME указана нереплицируемая таблица (явный запрет в replicate_*) — но это человеческий фактор
Суть в том, что в какой-то момент перестает работать tcp на 127.0.0.1, а пинги ходят без проблем. Проявлялось на нескольких разных машинах, рестарт контейнера не помогал.
по моему опыту: были задачи, когда mod_php мог обрабатывать до перезапуска тысячи запросов, а были и такие, когда приходилось передергивать через каждый десяток. причин я сильно не искал, но вот используемый во втором случае apc был зело крив и глючен.
imagick, например, также сильно зависит от библиотек и недавно мы поимели неприятную проблему с апгрейдом ImageMagick из-за старой версии lcms
все мы люди и склонны ошибаться :)
даже если мы ошибаемся редко — это не отменяетнеприятных последствий
Значит ли это, что пока не наберется max-requests, вассал будет возвращать ошибку на любые запросы?
упоминание HandlerSocket вполне соотносится с темой обзора: MySQL «на стероидах». не понимаю, что Вы так взъелись на это :)
>NoSQL — очевидно, сеонизаторский прием.
Это вы про HandlerSocket? По-моему, довольно классная штука — очень красиво оптимизировали узкую задачу — выборку по PK.
а можно мысль развить — почему их это пугает? и при чем тут бранчи?
в git как раз специально разделили процесс коммита файлов на 2 этапа — сначала формируется список изменений для следующего коммита, а потому уже они коммитятся. ключ -a сделан лишь для тех случаев, когда все изменения идут в один коммит (удобство)
откройте для себя git add -i — из всех изменений даже одного файла можно сформировать несколько отдельных коммитов