WapGraf: Евгений Русаченко, от такой команды там вовсе ничего поднимается и не может. На HDD в том же числе. wa должен оставаться равным 0.
Или вы о другой команде?
Я не о командах вообще, а о проблеме в целом :)
---------- Добавлено 15.06.2016 в 17:19 ----------
radl: Да это все понятно, просто внезапно так не должно быть. Я больше года сидел нормально все было. Но вдруг резко такая вот поведение сервера, вот что меня смущает.
И сваливать на hdd тоже не правильно, раньше вообще не было ssd и все нормально пользовались.
Да я это делал, я выше об этом писал, я все отключал и тестировал. wa примерно 0-2% . Но как я что то запускал где идет запись на диск, именно на запись то сразу же больше 45%
Например, простой apt-get upgrade который обновлялся (уже не помню что там я обновлял) около полу часа. А там пакетики в сумме 11мб весело всего. Параллельно сидел смотрел iotop и atop,
atop вообще краснел. Типа ALARM-ALARM)))
Да но она разве не показывает именно моего виртуального сервера. Как он может показать самого нода. К тому же они не смогли мне снять образ в течение 3-4 часов, снять образ который весит всего лишь 30ГБ. Сказали что за это время 1/3 часть удалось снять.
А сегодня как я перешел на SSD сняли за 10 минут. Это разве не говорит что у них что-то не так?
Я сам хостер, много слышал от клиентов - мой сайт внезапно перестал работать, мы ничего не делали. Зато делал кто-то другой (мошенники угоняли их пароли, хакеры взламывали сайт, спамеры забивали комментариями место в базе) и их сайт переставал работать. Вам же можно натравить пару десятков ботов и будут проблемы :) Клиент и хостер всегда смотрят по разному на проблемы, хостер смотрит данные сервера, если по ним всё хорошо (+ обычно если проблема массовая, клиенты засыпают тикетами проблему и сразу всё становится ясно), а клиент зачастую смотрит с точки зрения - я ничего не трогал, оно не могло сломаться / начать тормозить :) Я всегда люблю сказать, что сервер и сайты и это статический набор файлов, а постоянно меняющийся набор данных. Даже если Вы ничего не трогаете, от действий пользователей может поменяться логика данных и начать тормозить сайт или вовсе перестать работать. Причин может быть много, это всё надо грамотно исследовать и принимать меры.
Если в простое проблем не было (как Вы писали измеряли моим способом нагрузку), то это точно проблема на самом VDS. Вы видимо еще не сталкивались с серверами, когда стоит чистая операционная система, SSH ели ползает, а значения wa и st очень высокие :)
st - это показатель того, сколько процессорного времени не получил именно Ваш виртуальный сервер. Высокое значение данного показателя означает то, что установленного процессора на ноде недостаточно для всех клиентов, его ресурсов выделяют клиентам больше, чем у него сервера их есть.
wa - это показатель ожидания диска. Он полноценно связан целиком с нодой. Суть в том, что если на ноде диск перегружен, Вы будете ждать дольше обработку операций с диском и данный показатель будет высокий.
radl, Вы лично дома пользовались когда-нибудь SSD? Разница в работе HDD и SSD видна невооруженным взглядом, система грузится быстрее, операции все выполняются моментально. Если лично не пользовались, то посмотрите видео в сети загрузки операционных систем c SSD и с HDD, это как небо и земля. Еще очень чувствуется хорошо разница при работе с браузером, ибо он диск часто дергает (кеш). На серверах все аналогично, в рамках виртуальных серверов это очень хорошо ощутимо, так как диск не лично Вам выделен, а его используют и Ваши соседи по ноде :)
radl: Это не решение проблемы, я эти вещи знаю. Но это не выход.
У меня же кроме mysql есть и другие операции с диском.
Например, хотел обновить какой-то пакет, запустил apt-get upgrade и он обновляет пакет пол часа это нормально что-ли? А перезагрузка сервера, которая проходило максимум минуту, вдруг перезагружается где-то за полчаса это тоже?
Если запись на диск идет постоянно или даже чтение с диска, то для HDD это убийственно. Учитывайте то, что на сервере еще соседи. Средненький HDD имеет ограничений в 100 IOPS, учитывая то, что на сервере скорее всего не менее 10 соседей, то на каждого клиента приходится 10 iops. Если по простому, то операции с дисков свыше 10 (если строго считать) за единицу времени будут вставать в очередь и ждать завершения. Здесь варианта два - либо внутри контейнера проблема, либо на ноде, где лежит Ваш виртуальный сервер.
Проверяется легко - отключаете все процессы (mysql, httpd, nginx и прочие, которые взаимодействуют в диском), по сути, у Вас должен остаться минимальный набор процессов необходимый для работы операционный системы. Включаете top - если значения wa или st высоки, значит проблема на ноде. Также можно посмотреть load average. Но это всё верно будет только тогда, когда Вы на 100% уверены, что у Вас ничего не взаимодействует с диском на сервере и не грузит процессор.
Если первый тест выдал близкие к нулю значения wa и st, значит проблема внутри vds или Вам действительно просто не хватает ресурсов hdd. На ssd конечно же всё будет летать, там запаса iops хватит на всех клиентов с лихвой.
Блокировки и черные списки от Роскомнадзора - это большая головная боль для хостеров из-за этого некоторые просто отправляют сразу искать нового хостера при получении в адрес сайта клиента подобной жалобы.
Происходит это из-за того, что даже если попала лишь 1 страница сайта на сервере, то некоторые провайдеры блокируют доступ не к данной странице, а сразу к IP адресу сервера из-за чего страдают все клиенты, которые используют данный адрес.
Нормальная ли реакция хостера? Здесь каждый судит по своему, если у Вас действительно белый сайт и без проблемного контента и просто кто-то разместил какой-то спам, то можно было бы хостеру просто на уровне сервера ограничить доступ к проблемной странице и попросить удалить из базы контент. Если тематика сайта подозрительная, то лично я бы также заблокировал сразу весь сайт и отправил бы искать новый хостинг.
P.S. описанное - моё личное мнение из личного опыта.
smart2web: Почему это не работает? Все замечательно работает.
А как у Вас подключен PHP? Есть тонкость, если как CGI и процесс PHP всегда завершается после выполнения скрипта, то кеширования действительно не будет, ибо при новом запросе будет создан новый экземпляр PHP, где того самого кеша уже не будет. Вот если процессы PHP висят в idle и ожидают новых запросов, то тогда кеширование действительно есть.
Den73: там же идет стандартно 640, никто ничего там не прочитает как в 4 версии так в 5.
о каких именно паролях идет речь не понятно, там все через POST отсылается а он не логируется по умолчанию.
Hawen: В принципе CageFS "до лампочки" мне кажется, какая панель :)
Тут скорей всего вопрос в том, что панель "не смогла" настроить cagefs полностью
Не скажи... Писал плагин на ограничение числа файлов для пользователей ISPmanager 5, в итоге наблюдал интересную картину. cl-quota --user=имя_пользователя -H 100000 -S 100000 выдавало пользователь не найден. Писало так только для пользователей, которые были созданы через ISPmanager. Пообщавшись с поддержкой CloudLinux, сказали, что поддержки панели ISPmanager 5 с их стороны нет, они её только вот-вот добавили и порекомедовали обновить lve-utils из тестового репозитория, что помогло. Ошибка была вроде бы в том, что cl-quota искала список пользователей и тарифов (это файл /etc/container/user_plan.cache, а там было на подобии error: unknown panel).
А что с CageFS и Apache ITK пока непонятно... несколько лет работала такая связка, правда Apache ITK брал не из пакетов, а собирал из исходников с патчем от CloudLinux.
Den73: пусть, все равно там нет ничего интересного кроме списка аккаунтов в passwd
Я не специалист по безопасности, но как писал ранее - спится гораздо спокойнее, если даже /etc/passwd для пользователей закрыт :)
В ISPmanager 4 знаю, что если стоит проксирование и запросы в панель обрабатываются NGINX, то пароли всех пользователей светятся в /var/log/nginx/access.log, в 5 версии вроде бы всё хорошо в этом плане.
netwind: Вообще неправда. Затрагивает или нет можно путем закачки веб-шелла на php и попытке выбраться в чужой каталог.
С чего вы взяли что обычный для ispmanager способ с созданием групп и расстановкой прав перестал работать ? http://ru.ispdoc.com/index.php/Работа_с_пользователями_и_группами
Речь идет об обходе ограничения CageFS, а не о чтении файлов другого пользователя. За счет выставленных прав в указанной Вами документации прочитать чужой каталог действительно невозможно, но полазить по системе - вполне можно за счет обхода CageFS.
Также, если я верно понимаю, то в случае, если запрос не попадает в LVE, перестают работать ограничения установленные для пользователя на процессор, память, число соединений и процессов, что тоже не хорошо :)
Я вчера и сегодня общался с поддержкой CloudLinux, они подтвердили наличие проблемы конкретно на моём сервере. Также сказали, что клиентов с ISPmanager 5 у них мало и к ним пока с данной проблемой никто не обращался. В понедельник пообещали продолжить исследование работы подняв свою тестовую площадку. /usr/sbin/httpd.itk из их пакета с необходимыми патчами, Вы правы, V(o)ViK.
В режиме Apache Prefork работает корректно, запросы погружаются в LVE, в режиме ITK запросы не уходят в LVE из-за чего не работает CageFS.
Затрагивает ли Вас проблема можно проверить путем запуска команды:
cat /var/log/messages | grep "Can't enter lve from a slave context"
Если увидите сообщения вида:
_lve_enter: Can't enter lve from a slave context, pid 970293, oldve 48
xxmater: не открывается морда в браузере
я в него зайти не могу
https://dns-master.marosnet.net/dnsmgr Время ожидания ответа от сервера dns-master.marosnet.net истекло.
Возможно, сайт временно недоступен или перегружен запросами. Подождите некоторое время и попробуйте снова
хотя пинги идут
У меня зашло без проблем. Проверьте антивирус, фаервол, может что-то блокирует доступ. Хотя, может новый Anti-DDoS так работает...
Евгений Русаченко, от такой команды там вовсе ничего поднимается и не может. На HDD в том же числе. wa должен оставаться равным 0.
Или вы о другой команде?
Я не о командах вообще, а о проблеме в целом :)
---------- Добавлено 15.06.2016 в 17:19 ----------
Да это все понятно, просто внезапно так не должно быть. Я больше года сидел нормально все было. Но вдруг резко такая вот поведение сервера, вот что меня смущает.
И сваливать на hdd тоже не правильно, раньше вообще не было ssd и все нормально пользовались.
Да я это делал, я выше об этом писал, я все отключал и тестировал. wa примерно 0-2% . Но как я что то запускал где идет запись на диск, именно на запись то сразу же больше 45%
Например, простой apt-get upgrade который обновлялся (уже не помню что там я обновлял) около полу часа. А там пакетики в сумме 11мб весело всего. Параллельно сидел смотрел iotop и atop,
atop вообще краснел. Типа ALARM-ALARM)))
Да но она разве не показывает именно моего виртуального сервера. Как он может показать самого нода. К тому же они не смогли мне снять образ в течение 3-4 часов, снять образ который весит всего лишь 30ГБ. Сказали что за это время 1/3 часть удалось снять.
А сегодня как я перешел на SSD сняли за 10 минут. Это разве не говорит что у них что-то не так?
Я сам хостер, много слышал от клиентов - мой сайт внезапно перестал работать, мы ничего не делали. Зато делал кто-то другой (мошенники угоняли их пароли, хакеры взламывали сайт, спамеры забивали комментариями место в базе) и их сайт переставал работать. Вам же можно натравить пару десятков ботов и будут проблемы :) Клиент и хостер всегда смотрят по разному на проблемы, хостер смотрит данные сервера, если по ним всё хорошо (+ обычно если проблема массовая, клиенты засыпают тикетами проблему и сразу всё становится ясно), а клиент зачастую смотрит с точки зрения - я ничего не трогал, оно не могло сломаться / начать тормозить :) Я всегда люблю сказать, что сервер и сайты и это статический набор файлов, а постоянно меняющийся набор данных. Даже если Вы ничего не трогаете, от действий пользователей может поменяться логика данных и начать тормозить сайт или вовсе перестать работать. Причин может быть много, это всё надо грамотно исследовать и принимать меры.
Если в простое проблем не было (как Вы писали измеряли моим способом нагрузку), то это точно проблема на самом VDS. Вы видимо еще не сталкивались с серверами, когда стоит чистая операционная система, SSH ели ползает, а значения wa и st очень высокие :)
st - это показатель того, сколько процессорного времени не получил именно Ваш виртуальный сервер. Высокое значение данного показателя означает то, что установленного процессора на ноде недостаточно для всех клиентов, его ресурсов выделяют клиентам больше, чем у него сервера их есть.
wa - это показатель ожидания диска. Он полноценно связан целиком с нодой. Суть в том, что если на ноде диск перегружен, Вы будете ждать дольше обработку операций с диском и данный показатель будет высокий.
radl, Вы лично дома пользовались когда-нибудь SSD? Разница в работе HDD и SSD видна невооруженным взглядом, система грузится быстрее, операции все выполняются моментально. Если лично не пользовались, то посмотрите видео в сети загрузки операционных систем c SSD и с HDD, это как небо и земля. Еще очень чувствуется хорошо разница при работе с браузером, ибо он диск часто дергает (кеш). На серверах все аналогично, в рамках виртуальных серверов это очень хорошо ощутимо, так как диск не лично Вам выделен, а его используют и Ваши соседи по ноде :)
Это не решение проблемы, я эти вещи знаю. Но это не выход.
У меня же кроме mysql есть и другие операции с диском.
Например, хотел обновить какой-то пакет, запустил apt-get upgrade и он обновляет пакет пол часа это нормально что-ли? А перезагрузка сервера, которая проходило максимум минуту, вдруг перезагружается где-то за полчаса это тоже?
Если запись на диск идет постоянно или даже чтение с диска, то для HDD это убийственно. Учитывайте то, что на сервере еще соседи. Средненький HDD имеет ограничений в 100 IOPS, учитывая то, что на сервере скорее всего не менее 10 соседей, то на каждого клиента приходится 10 iops. Если по простому, то операции с дисков свыше 10 (если строго считать) за единицу времени будут вставать в очередь и ждать завершения. Здесь варианта два - либо внутри контейнера проблема, либо на ноде, где лежит Ваш виртуальный сервер.
Проверяется легко - отключаете все процессы (mysql, httpd, nginx и прочие, которые взаимодействуют в диском), по сути, у Вас должен остаться минимальный набор процессов необходимый для работы операционный системы. Включаете top - если значения wa или st высоки, значит проблема на ноде. Также можно посмотреть load average. Но это всё верно будет только тогда, когда Вы на 100% уверены, что у Вас ничего не взаимодействует с диском на сервере и не грузит процессор.
Если первый тест выдал близкие к нулю значения wa и st, значит проблема внутри vds или Вам действительно просто не хватает ресурсов hdd. На ssd конечно же всё будет летать, там запаса iops хватит на всех клиентов с лихвой.
Доброй ночи.
Блокировки и черные списки от Роскомнадзора - это большая головная боль для хостеров из-за этого некоторые просто отправляют сразу искать нового хостера при получении в адрес сайта клиента подобной жалобы.
Происходит это из-за того, что даже если попала лишь 1 страница сайта на сервере, то некоторые провайдеры блокируют доступ не к данной странице, а сразу к IP адресу сервера из-за чего страдают все клиенты, которые используют данный адрес.
Нормальная ли реакция хостера? Здесь каждый судит по своему, если у Вас действительно белый сайт и без проблемного контента и просто кто-то разместил какой-то спам, то можно было бы хостеру просто на уровне сервера ограничить доступ к проблемной странице и попросить удалить из базы контент. Если тематика сайта подозрительная, то лично я бы также заблокировал сразу весь сайт и отправил бы искать новый хостинг.
P.S. описанное - моё личное мнение из личного опыта.
Почему это не работает? Все замечательно работает.
А как у Вас подключен PHP? Есть тонкость, если как CGI и процесс PHP всегда завершается после выполнения скрипта, то кеширования действительно не будет, ибо при новом запросе будет создан новый экземпляр PHP, где того самого кеша уже не будет. Вот если процессы PHP висят в idle и ожидают новых запросов, то тогда кеширование действительно есть.
там же идет стандартно 640, никто ничего там не прочитает как в 4 версии так в 5.
о каких именно паролях идет речь не понятно, там все через POST отсылается а он не логируется по умолчанию.
Плагин для WHMCS по API передает данные пользователя в GET параметре: http://ru.ispdoc.com/index.php/API_result_is_%22ok%22, в итоге в логах подобное:
GET /manager/ispmgr?func=reseller&authinfo=данные_пользователя&out=json HTTP/1.1
Права на файл 640, Вы правы.
В принципе CageFS "до лампочки" мне кажется, какая панель :)
Тут скорей всего вопрос в том, что панель "не смогла" настроить cagefs полностью
Не скажи... Писал плагин на ограничение числа файлов для пользователей ISPmanager 5, в итоге наблюдал интересную картину. cl-quota --user=имя_пользователя -H 100000 -S 100000 выдавало пользователь не найден. Писало так только для пользователей, которые были созданы через ISPmanager. Пообщавшись с поддержкой CloudLinux, сказали, что поддержки панели ISPmanager 5 с их стороны нет, они её только вот-вот добавили и порекомедовали обновить lve-utils из тестового репозитория, что помогло. Ошибка была вроде бы в том, что cl-quota искала список пользователей и тарифов (это файл /etc/container/user_plan.cache, а там было на подобии error: unknown panel).
А что с CageFS и Apache ITK пока непонятно... несколько лет работала такая связка, правда Apache ITK брал не из пакетов, а собирал из исходников с патчем от CloudLinux.
пусть, все равно там нет ничего интересного кроме списка аккаунтов в passwd
Я не специалист по безопасности, но как писал ранее - спится гораздо спокойнее, если даже /etc/passwd для пользователей закрыт :)
В ISPmanager 4 знаю, что если стоит проксирование и запросы в панель обрабатываются NGINX, то пароли всех пользователей светятся в /var/log/nginx/access.log, в 5 версии вроде бы всё хорошо в этом плане.
Вообще неправда. Затрагивает или нет можно путем закачки веб-шелла на php и попытке выбраться в чужой каталог.
С чего вы взяли что обычный для ispmanager способ с созданием групп и расстановкой прав перестал работать ? http://ru.ispdoc.com/index.php/Работа_с_пользователями_и_группами
Речь идет об обходе ограничения CageFS, а не о чтении файлов другого пользователя. За счет выставленных прав в указанной Вами документации прочитать чужой каталог действительно невозможно, но полазить по системе - вполне можно за счет обхода CageFS.
Также, если я верно понимаю, то в случае, если запрос не попадает в LVE, перестают работать ограничения установленные для пользователя на процессор, память, число соединений и процессов, что тоже не хорошо :)
Я вчера и сегодня общался с поддержкой CloudLinux, они подтвердили наличие проблемы конкретно на моём сервере. Также сказали, что клиентов с ISPmanager 5 у них мало и к ним пока с данной проблемой никто не обращался. В понедельник пообещали продолжить исследование работы подняв свою тестовую площадку. /usr/sbin/httpd.itk из их пакета с необходимыми патчами, Вы правы, V(o)ViK.
В режиме Apache Prefork работает корректно, запросы погружаются в LVE, в режиме ITK запросы не уходят в LVE из-за чего не работает CageFS.
Затрагивает ли Вас проблема можно проверить путем запуска команды:
Если увидите сообщения вида:
Значит Вы под угрозой.
не открывается морда в браузере
я в него зайти не могу
https://dns-master.marosnet.net/dnsmgr
Время ожидания ответа от сервера dns-master.marosnet.net истекло.
Возможно, сайт временно недоступен или перегружен запросами. Подождите некоторое время и попробуйте снова
хотя пинги идут
У меня зашло без проблем. Проверьте антивирус, фаервол, может что-то блокирует доступ. Хотя, может новый Anti-DDoS так работает...