http://pecl.php.net/package/memtrack вот оказывается еще что есть.
но для проверять утечки в модулях и в apache кажется не получится.
которая на самом деле банальный ulimit и от которой апач падает, так не успев записать в каком именно запросе он съел память.
могу только посоветовать mod_log_slow модифицировать. там почти весь код уже есть, нужно еще и память добавить,
Maxxi, именно так. если конечно нет утечки, но это уже форс-мажор.
Кое-какой выход я тут предложил /ru/forum/comment/4565475.
Утечкой памяти называют совсем другое поведение. Здесь просто потомки apache потребляют память, но не отдают отбратно операционной системе при каждом запросе. Чем потомок больше работает - тем больше шансов на разрастание.
Обычно это правильная стратегия, ведь каждому следущему запросу вероятно потребуется столько же памяти сколько и предыдущему.
Регулируйте, раз нашли как :) MaxClients тоже неплохо бы подобрать не очень большое.
По-моему webo.in кеширует результаты внутри себя.
Если зарегистрироваться, то можно несколько раз подавать новые запросы.
Неплохой сервис, кстати, хоть и представляет из себя рекламу их собственных услуг.
абсолютно идентично только вместо "mysql" надо написать полный путь к mysql.exe
вы не поверите! mysql.exe
f0x, так какой хостер и площадка ? мы внимательно записываем
Или ваша площадка - отморозки . Бы же инцидент с mchost /ru/forum/270122
почему бы ему не повториться.
Обычно это сортировки, листалки до последней страницы и тому подобные вещи, которые никто в реальной жизни не вызывает. Этим даже яндекс.маркет страдает.
Вот что интересно - скрипт от ддоса ведь не спасет. Чтобы уложить дохлый VPS достаточно пяток неудобных запросов. Это слишком мало для срабатывания обычных критериев блокировки ддос.
Лучше ограничить число неудобных запросов по времени в коде или еще что-то придумать.
Вот на этом форуме, например, поиск раз в 60 секунд можно делать.
