Ещё один день, ещё одна победа
Nov. 8th, 2010 04:43 pm![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
Маленькая рабочая зарисовочка.
На вверенный мне в подчинение сервачок (виртуальный сервер, под win2003) сливаются по FTP кой-какие логи, примерно по 12-15 гигов за сутки. Файлики разбиты по восемь мегабайт, итого по полторы-две тысячи файлов в сутки. Всё пишется в один каталог.
Кроме этого на серваке крутится апач, база данных и несколько самодельных серверов, в общем, без нагрузки он не простаивает.
Ну работает он и работает, всё ОК.
Но логи, о которых я в начале сказал, просто так хранить неудобно. И весят они много, и с кучей файлов неудобно работать. Что нужно сделать? Пожать, благо голый текст же.
Ок, пишу небольшой скриптик, который берёт все файлы за день, скармливает их в rar, а после архивации удаляет. Тестирую, всё отлично работает.
Запускаю на рабочем серваке в тест - всё отлично, первый архив выпекается за полчаса.
Запускаю снова - всё тормозит ппц как, ожидаемое время создания одного архива - три часа... пять часов... Загрузка CPU и памяти - в пределах нормы, загрузка диска - тоже.
Но тормозит всё капец как, даже листинг каталогов в файловом менеджере минуту читается. После ребута снова так - первый прогон начинается нормально, но потом вдруг всё опять начинает тормозить, иногда даже до завершения архивации. Копирование или даже перемещение файла - считанные байты в секунду, независимо от способа копирования.
Запускаю менеджер производительности, тыкаюсь в статистику загрузки дисков - огромные задержки при записи. Но при этом в менеджере процессов у всех задач нагрузка на диск не больше и не меньше, чем обычно, и даже суммарно не должна представлять никаких проблем.
Подумать над тем, что послужило причиной тормозов, и как это обнаружить, я предоставляю вам. Всю необходимую информацию я в посте дал. Комменты скринятся, правильный ответ опубликую завтра.
UPD: Упустил из вида немаловажную деталь - тормоза начинаются после перезагрузки вне зависимости от того, запускается ли архивация, или нет. Т.е. чуть-чуть поработает, а потом бдыщ - и тормозит.
Первая мысль, которая мне пришла в голову - проблема с самой виртуалкой. Простой выход - спихнуть проблему админам. Простой, но не всегда правильный.
Перезагружаю сервер без рестарта выполняемых им задач. Всё летает, как и должно. Вывод - проблема в одном (или нескольких) работающих приложениях.
Начинаю стартовать сервисы по одному, и тормоза всегда начинаются после запуска mysqld. А это невозможно, потому что нагрузки на диск мускул не создаёт почти никакой.
Прибиваю mysqld - проблема остаётся. Значит он не при чём.
Так, методом исключения нахожу корень проблемы. Это FTP-сервер (я использовал старый, но удобный и проверенный Ability FTP).
Дело в том, что каждый раз, когда кто-то обращался к серверу (а это, как правило, случалось только через несколько минут после рестарта), тот перечитывал список файлов (а их, к тому времени, было около тридцати тысяч в одном каталоге). А учитывая, что обращения к FTP были чаще, чем сервер успевал закончить считывание, просраться серверу было не суждено.
Что забавно: список ровно до 20000 файлов сервер считывает моментально. 20001 файл - всё, тормоза (потому глюк раньше и не проявлялся, за двадцать тысяч количество файлов перевалило относительно недавно). То ли это глюк системы, то ли самого FTP-сервера, не знаю, но вероятнее всё-таки второе. Остальные программы даже сотню тысяч файлов читают моментально.
UPD2: это действительно глюк FTP, обновлённая версия читает большой список быстро, и не создаёт нагрузки.
На вверенный мне в подчинение сервачок (виртуальный сервер, под win2003) сливаются по FTP кой-какие логи, примерно по 12-15 гигов за сутки. Файлики разбиты по восемь мегабайт, итого по полторы-две тысячи файлов в сутки. Всё пишется в один каталог.
Кроме этого на серваке крутится апач, база данных и несколько самодельных серверов, в общем, без нагрузки он не простаивает.
Ну работает он и работает, всё ОК.
Но логи, о которых я в начале сказал, просто так хранить неудобно. И весят они много, и с кучей файлов неудобно работать. Что нужно сделать? Пожать, благо голый текст же.
Ок, пишу небольшой скриптик, который берёт все файлы за день, скармливает их в rar, а после архивации удаляет. Тестирую, всё отлично работает.
Запускаю на рабочем серваке в тест - всё отлично, первый архив выпекается за полчаса.
Запускаю снова - всё тормозит ппц как, ожидаемое время создания одного архива - три часа... пять часов... Загрузка CPU и памяти - в пределах нормы, загрузка диска - тоже.
Но тормозит всё капец как, даже листинг каталогов в файловом менеджере минуту читается. После ребута снова так - первый прогон начинается нормально, но потом вдруг всё опять начинает тормозить, иногда даже до завершения архивации. Копирование или даже перемещение файла - считанные байты в секунду, независимо от способа копирования.
Запускаю менеджер производительности, тыкаюсь в статистику загрузки дисков - огромные задержки при записи. Но при этом в менеджере процессов у всех задач нагрузка на диск не больше и не меньше, чем обычно, и даже суммарно не должна представлять никаких проблем.
Подумать над тем, что послужило причиной тормозов, и как это обнаружить, я предоставляю вам. Всю необходимую информацию я в посте дал. Комменты скринятся, правильный ответ опубликую завтра.
UPD: Упустил из вида немаловажную деталь - тормоза начинаются после перезагрузки вне зависимости от того, запускается ли архивация, или нет. Т.е. чуть-чуть поработает, а потом бдыщ - и тормозит.
Первая мысль, которая мне пришла в голову - проблема с самой виртуалкой. Простой выход - спихнуть проблему админам. Простой, но не всегда правильный.
Перезагружаю сервер без рестарта выполняемых им задач. Всё летает, как и должно. Вывод - проблема в одном (или нескольких) работающих приложениях.
Начинаю стартовать сервисы по одному, и тормоза всегда начинаются после запуска mysqld. А это невозможно, потому что нагрузки на диск мускул не создаёт почти никакой.
Прибиваю mysqld - проблема остаётся. Значит он не при чём.
Так, методом исключения нахожу корень проблемы. Это FTP-сервер (я использовал старый, но удобный и проверенный Ability FTP).
Дело в том, что каждый раз, когда кто-то обращался к серверу (а это, как правило, случалось только через несколько минут после рестарта), тот перечитывал список файлов (а их, к тому времени, было около тридцати тысяч в одном каталоге). А учитывая, что обращения к FTP были чаще, чем сервер успевал закончить считывание, просраться серверу было не суждено.
Что забавно: список ровно до 20000 файлов сервер считывает моментально. 20001 файл - всё, тормоза (потому глюк раньше и не проявлялся, за двадцать тысяч количество файлов перевалило относительно недавно). То ли это глюк системы, то ли самого FTP-сервера, не знаю, но вероятнее всё-таки второе. Остальные программы даже сотню тысяч файлов читают моментально.
UPD2: это действительно глюк FTP, обновлённая версия читает большой список быстро, и не создаёт нагрузки.
no subject
Date: 2010-11-09 05:50 am (UTC)