40 МБит / сек — неплохой трафик для DoS атаки. Именно на столько внезапно вырос входящий трафик до одного из наших серверов. Сайт мужественно держался. Время начала всплеска аномально высокого трафика подозрительно точно совпадало с временем выкладывания одного крупного релиза, что и навело на мысль о том что мы DoS`им себя сами.
Ситуацию осложняло то, что в релиз попали изменения порядка сотни разных php-файлов и просмотреть весь список изменений было очень трудоёмко. tcpdump помог выяснить что трафик вырос до сервера баз данных PostgreSQL. Круг сужался.
Первым предположение было то что в одном из SQL-запросов забыли limit и он выбирает весь набор данных вместо одной строки. Но как узнать что это за запрос? На помощь пришёл pgFouine. Анализ лога работы сервера баз данных за две минуты и вот он — источник зла!
Вот он — запрос без limit`а, который выполнялся тысячи раз. Но в наших исходниках не было этого запроса! Нигде, ни в одном файле он не встречался.
Источник проблемы скрывался в php-функции pg_field_type, которая всего навсего возвращала символьное имя типа колонки результата выборки.
Проблема уходит своими корнями как минимум в 2005 год но до сих пор в официальной документации не добавлено замечание о то, что библиотека php-pgsql для доступа к PostgreSQL делает дополнительный запрос к СУБД выбирая полный список из более чем 1000 типов данных.
Возможно на редко посещаемом сайте это совсем не сказывается на быстродействии, но на нагруженном проекте это может создать серьёзную проблему. Мы обошли проблему, использовав вместо функции pg_field_type её аналог pg_field_type_oid, которая возвращает внутренний oid типа данных вместо его символьного имени. Да, это немного ухудшило читабельность кода, но разгрузило канал до сервера баз данных на 40 МБит.
Возможно если бы мы использовали True FastCGI, то у нас бы не было это проблемы, но php стал готов к этому всего несколько месяцев назад, а проблема существует уже около 6 лет.
Поищите в ваших исходниках по ключевому слову pg_field_type — возможно вы сможете очень облегчить тяжёлую жизнь вашего сервера PostgreSQL.
Ситуацию осложняло то, что в релиз попали изменения порядка сотни разных php-файлов и просмотреть весь список изменений было очень трудоёмко. tcpdump помог выяснить что трафик вырос до сервера баз данных PostgreSQL. Круг сужался.
Первым предположение было то что в одном из SQL-запросов забыли limit и он выбирает весь набор данных вместо одной строки. Но как узнать что это за запрос? На помощь пришёл pgFouine. Анализ лога работы сервера баз данных за две минуты и вот он — источник зла!
select oid,typname from pg_typeВот он — запрос без limit`а, который выполнялся тысячи раз. Но в наших исходниках не было этого запроса! Нигде, ни в одном файле он не встречался.
Источник проблемы скрывался в php-функции pg_field_type, которая всего навсего возвращала символьное имя типа колонки результата выборки.
Проблема уходит своими корнями как минимум в 2005 год но до сих пор в официальной документации не добавлено замечание о то, что библиотека php-pgsql для доступа к PostgreSQL делает дополнительный запрос к СУБД выбирая полный список из более чем 1000 типов данных.
Возможно на редко посещаемом сайте это совсем не сказывается на быстродействии, но на нагруженном проекте это может создать серьёзную проблему. Мы обошли проблему, использовав вместо функции pg_field_type её аналог pg_field_type_oid, которая возвращает внутренний oid типа данных вместо его символьного имени. Да, это немного ухудшило читабельность кода, но разгрузило канал до сервера баз данных на 40 МБит.
Возможно если бы мы использовали True FastCGI, то у нас бы не было это проблемы, но php стал готов к этому всего несколько месяцев назад, а проблема существует уже около 6 лет.
Поищите в ваших исходниках по ключевому слову pg_field_type — возможно вы сможете очень облегчить тяжёлую жизнь вашего сервера PostgreSQL.
