Vesta Control Panel - Forum

fdorenelin wrote:Тогда нужно поставить пользователей в известность: Веста из "коробки" завалит мощный сервер при одновременной посещаемости в 20-30 человек, на всех ОС.

Извините, но это не просто не так, а очень сильно не так. Ваши заявления хоть и со смайликом не соответствуют действительности. Серверы как работали, так и работают. Не так давно ставил на впс с сайтом на 3-4к хостов в сутки и тоже проблем не видно. Настраивать нужно, настраивать. Я же предложил в одном из ваших топиков посмотреть, вы почему-то не отреагировали - viewtopic.php?f=29&t=9836&p=35133#p35183

fdorenelin wrote:А тут много пользователей у кого сайты посещаемые ???? Хотябы 1000 пользователей?

Суммарно сайтам на сервере даже больше.

fdorenelin wrote:Поэтому, сейчас веста годится для сайтов с одновременной посещаемостью до 20-30 челов)

Ну что тут скажешь, плохому танцору...

Я же предложил в одном из ваших топиков посмотреть, вы почему-то не отреагировали - viewtopic.php?f=29&t=9836&p=35133#p35183

А зачем? Гораздо легче обвинять разработчиков и панель.

Проверил через лоадимпакт 25 + еще 3-4 запроса от разных серверов стабильно держит, зря грешите на панель
памяти 2Гб и 4е ядра на xene работает отлично, конечно не привычно пользоваться панелью накладываются отпечаток делать все вручную, особенно когда нужен revers proxy или еще не стандартное тут приходится писать конфиг под каждый проект(есть боязнь, что конфиги могут быть перезаписаны, но удобно для других, кто не пользуется консолью, а ошибки с mysql устраняются, где то в разделе bd писал об этом.

Спасибо за тест )

taku wrote:особенно когда нужен revers proxy или еще не стандартное тут приходится писать конфиг под каждый проект(есть боязнь, что конфиги могут быть перезаписаны, но удобно для других, кто не пользуется консолью,

Имеет смысл шаблонизировать какие-то частые вещи - вероятность перезаписи будет сильно ниже.
А при обновлении ПО опять же делать копии конфигов, просто на всякий случай. )

taku wrote:а ошибки с mysql устраняются, где то в разделе bd писал об этом.

mysql очень любит память, только кастомизация конфигов )

Кому из ветки интересно, чем закончилось с fdorenelin, то вот итоге - viewtopic.php?f=29&t=9836&start=20#p35265 - все дело в том, что шла туча запросов с других серверов от ApacheBench (основная причина).

skurudo wrote:Кому из ветки интересно, чем закончилось с fdorenelin, то вот итоге - viewtopic.php?f=29&t=9836&start=20#p35265 - все дело в том, что шла туча запросов с других серверов от ApacheBench (основная причина).

Да и судя по сайту "Poker After Dark" Человек который это делал знал что делает. Такие сайты как магнит тянут всю не честь, особенно если сайт еще и бабло берет или всякие кряки патчи. А обычный сайт с движками joomla, wordpress dle , итд используется для рассылки спама. Пример (viewtopic.php?p=34513#p34513)
Да и перед тем ставить свой сайт на панель управления vestacp подумайте над своим контентом, настройками. *Я не думаю что не что подобное смогут выдержать другие панели на таком железе. "Если руки крюки то глаз алмаз не поможет."

skurudo wrote:Кому из ветки интересно, чем закончилось с fdorenelin, то вот итоге - viewtopic.php?f=29&t=9836&start=20#p35265 - все дело в том, что шла туча запросов с других серверов от ApacheBench (основная причина).

Могу сам рассказать.
Сразу откуда уверенность про ApacheBench? По вашей ссылке, инфа - утилита устанавливается непосредственно на сервер.
Из скрина, видно, что сервер перегружен, а что его грузит – не понятно. Непонятно было тогда, не понятно сейчас.
Я не исключаю атаку. Моё первое мнение то же было об атаке. Нет доказательств атаки. На сервере ставил и модуль modsecurity + iptables и fail2ban стоят по умолчанию. Ддос + время атакующему будут дороже чем вся затея.
Что касается сервера:

# Limit connection
limit_conn_zone $binary_remote_addr zone=one:4m;
limit_conn one 3;
limit_req_status 444;
limit_req_zone $binary_remote_addr zone=requests:10m rate=2r/s;
limit_req zone=requests burst=5;

if ($http_user_agent ~* (ApacheBench|ApacheBench/2.3)) {
return 444; }

Связка недолго поработала, и стал валится сам сайт. Код убрал, - всё заработало.
С кодом, действительно тестить сервер не получалось, тот же app.loadimpact.com - не мог тестить.

Кроме кода поправил конфиг nginx , теперь он, в основном такой:

worker_connections 8040;
http {
# Main settings
sendfile on;
#Расширяем буфера отдачи
#output_buffers 32 512k;
#Ограничиваем размер сегмента отправляемой за одну
#блокируемую отдачу
sendfile_max_chunk 128k;
#Буфер отдачи которы используется для обрабатываемых данных
postpone_output 1460;
#Размер хеша для доменных имен.
server_names_hash_bucket_size 64;
#Размер данных принемаемых post запросом
client_max_body_size 15m;
tcp_nopush on;
tcp_nodelay on;
keepalive_timeout 65;
types_hash_max_size 2048;
# При ошибках не говорим врагу версию nginx
server_tokens off;

Сейчас при тесте с сайта app.loadimpact.com, сервер даже не повышает нагрузку. Пока сервер работает прекрасно. Но подозреваемому в атаке – бывшему полубандитскому хостингу письмо отправил, а других подозреваемых и врагов нет.

Да, всётаки сервер падает примерно с 11-00 до 24-00. Моё мнение, сервер скоро снова упадет. ApacheBench можно применить к моему серверу для пробы? Или как еще создать нагрузку удалённо, и проверить сервер?

Если это дос отключите фаером, если ддос смотрите в сторону клоудфларе если память не изменяет, то вроде вплоть до 7 уровня!

fdorenelin wrote: Сразу откуда уверенность про ApacheBench? По вашей ссылке, инфа - утилита устанавливается непосредственно на сервер.

Из логов и useg-agеnt в тех же логах

fdorenelin wrote:Из скрина, видно, что сервер перегружен, а что его грузит – не понятно. Непонятно было тогда, не понятно сейчас. Я не исключаю атаку. Моё первое мнение то же было об атаке. Нет доказательств атаки.

Второй скрип показывает, кого блокировали по большей части, вот там вам ApacheBench

fdorenelin wrote:ApacheBench можно применить к моему серверу для пробы? Или как еще создать нагрузку удалённо, и проверить сервер?

Может вы сами как-то в интернете почитаете?

http://lmgtfy.com/?q=ApacheBench+%D1%82 ... 0%B8%D0%B5