Как мелкий баг может привести к большому падению
Мда, иногда мелкая недоработка в глубоко вспомогательной функции может вызвать падение сайта целиком. Так было и сегодня с 4xpro.ru. Когда-то я добавил тег blocklink для вставки ссылок с автоматической догрузкой названия/описания/картинки через OpenGraph, чтобы ссылки выглядели блоком с предпросмотром, как в соцсетях. Какое-то время это работало, потом обратил внимание, что почему-то для некоторых ссылок данные не подгрузились. Решил, что заглючил вызов скрипта cron.php по crontab и отложил выяснение этого вопроса до лучших времён, поскольку это было не столь критично.
Но увы, вместо лучших времён настали худшие: сегодня упал сайт целиком с очень необычной ошибкой — переполнение MEMORY-таблицы ib_online со списком тех, кто сейчас на форуме. В норме эта таблица должна была регулярно очищаться, и такое переполнение возможно разве что при slashdot-эффекте.
Видя это дело, зашёл с консоли, запустил скрипт cron.php вручную и очень удивился результату: он выпал с ошибкой. Оказалось, что когда я делал blocklink, я в при разборе ответа сервера на наличие тега og:type неправильно сделал проверку на то, что он пуст: вместо if (!empty($og_type[0])) написал if (!empty($og_url[0])) (видимо, результат копирования похожего кода парой строк выше). А дальше следовал вызов $og_type[0]->getAttribute('content'), который и приводил к тому, что скрипт падал. Причём срабатывало это только в том случае, если в списке задач для обработки была ссылка на страницу, где og:url есть, а og:type — нет, поэтому поймать такое на этапе тестирования было сложно.
В итоге из-за этой ошибки и падения скрипта задачи по очистке устаревших данных просто не запускались, MySQL ел всё больше и больше памяти (и дочерние процессы иногда падали по OOM), производительность деградировала, но пока сайт не упал целиком, я даже не представлял, насколько всё серьёзно (да и в голову не пришло бы, что нужно "копать" blocklink).
Но увы, вместо лучших времён настали худшие: сегодня упал сайт целиком с очень необычной ошибкой — переполнение MEMORY-таблицы ib_online со списком тех, кто сейчас на форуме. В норме эта таблица должна была регулярно очищаться, и такое переполнение возможно разве что при slashdot-эффекте.
Видя это дело, зашёл с консоли, запустил скрипт cron.php вручную и очень удивился результату: он выпал с ошибкой. Оказалось, что когда я делал blocklink, я в при разборе ответа сервера на наличие тега og:type неправильно сделал проверку на то, что он пуст: вместо if (!empty($og_type[0])) написал if (!empty($og_url[0])) (видимо, результат копирования похожего кода парой строк выше). А дальше следовал вызов $og_type[0]->getAttribute('content'), который и приводил к тому, что скрипт падал. Причём срабатывало это только в том случае, если в списке задач для обработки была ссылка на страницу, где og:url есть, а og:type — нет, поэтому поймать такое на этапе тестирования было сложно.
В итоге из-за этой ошибки и падения скрипта задачи по очистке устаревших данных просто не запускались, MySQL ел всё больше и больше памяти (и дочерние процессы иногда падали по OOM), производительность деградировала, но пока сайт не упал целиком, я даже не представлял, насколько всё серьёзно (да и в голову не пришло бы, что нужно "копать" blocklink).