Та ну, клиенты сразу за нами :)
Ну да.
. ядро 26-е вполне подходит под то время.
Так что глюк, который надо патчить, не мог же скрываться 2 года :). Высока вероятность того, что патчить нечего.
Andreyka скорее всего этого делать нельзя, процесс 120 секунд не может сдвинуться никуда из-за ОС. Матюгальник можно то выключить, но это же не решит саму проблему.
А КВМ есть чтоб в биосе потыкать?
Не нужно смотреть, не лечится изнутри.
99,99% это блокировка вызвана остановкой/приостановкой обмена данными (т.н. freeze) с внешними накопителями у хостовой ОС, которая держит ваш ВДС.
Если жадненький хостер - то это и bad blocks могут быть на его винтах :)
Тут без знаний архитектуры построения хостера ( которую никто не скажет просто так) не скажешь ничего, но это и неважно.
Вы ошибаетесь, считая одинхостер-одинсервер-одинчеловек.
У меня на этом форуме постов с десяток, да я только перешел из ридонли :)
А вот про клона в сторону человека как-то нехорошо звучит.
А как же получилось не ходя в шелл сломать права :)
Так что, исправили?
Макеевка, не гони волну.
Да и почему не могу. Уже целую станицу Вам предлагают то же, то и я. Я ж не говорю "Вандамко-поломалко опять что-то сломало гы-гы-гы". Я дал вполне конкретное направление дял исправления ситуации. Выполнение "ниасилил" ?
1. Самый важный вопрос. Шибко ли мешает ли такое ЛА работе сервера? Напрмер ЛА в *bsd и линухе - шибко разные параметры. В линухе есть такая штука как wa, это ожидание (простой) на вводе-выводе. Так так винт всегда медленнее проца, то при операциях копирования wa растет всегда. Думаю что гугл подробней вполне может рассказать про la.
2. "Гадкая панелька" :), я беззлобно (ИСПманагер не выставляет сам этот параметр). Апач - прожорливая штука. Может скушать под нагрузкой чуть больше чем есть и свалить сервер. У него по этому поводу есть в файле /etc/apache2/apache2.conf параметр MaxClients. Он ограничивает количество процессов апача. Если дефолтая установка и никто шибко руками в конфиге этом не рылся, то там этот параметр находится в нескольких секциях. В подавляющем большистве конфигов (включая Ваш случай) модно спокойно менять этот паратр во всех секциях. Теперь попробует посчитать, сколько туда надо поставить. Писать тяжелее, чем считать :). Нужно сделать так, чтобы при максимальном количестве клиентов и наибольшем выделении памяти для апача, сервер на падал в своп. вебсервер в свопе не работает :). Не забывайте про мускуль, ему тоже нужна память . Ну и прочие процессы. Для выяснения что у происходит с памятью - в помощь комманды: free -m, top, ps aux. Ну и греп.
Почему плодятся апачи при архивации. Потому что приходят новые клиенты к апачу за контентом, а у него "все занято", т.к. он еще не устал отдать контент предыдущим. А ограничение где-то далеко, вот он и плодит их дальше, усугубляя ситуацию.
Если не трогать приоритеты процессов, то бубунта ровно поделит процессорное время между всеми пользовательскими процессами, таренье не должно так отбирать проц у апачей, что прямо им там плохо - апачей много, а тар один.
Теперь про диски.
Абсолютно правильное направление ionice
В бубе есть
iotop
iostat (пакет sysstat)
Нужно посмотреть, насколько загружена дисковая подсистема под обычной нагрузкой, без тара.
iotop сможет показать чем нагружена, именно каким процессом.
Если в притык, то без ионайса вообще никак.
Удачных раскопок!
madoff, это ж vandamme :)
Там скорее df -ih а потом find'ом их мочить, т.к. вполне от простого rm'a можно получить "Argument list too long"
vandamme, ssh баловались ? ;)
