LINUX.ORG.RU
ФорумAdmin

Высокий LA, периодические зависания соединений

 , , , ,


0

1

Здравствуйте.

Сервер на SSD, 64GB RAM, 12 ядер, стоит Debian 7, на сервере работают сайты в связке Apache, Nginx, PHP, MySQL, Sphinx. Долгое время уровень LA держался на уровне 25-30, подтормаживало, не супер критично, работы было много, откладывали это дело всегда в долгий ящик. Когда LA улетал до 50-70-100, перезагружали Apache или сам сервер, LA приходил к норме, работали дальше.

Полгода назад решил заняться этим вопросом. Сам я нуб в Linux, работал на уровне поставить программу по инструкции, покрутить настройки Mysql, Apache по статейкам в интернете (пальцем в небо). Начал разбираться, узнал, что такое access-логи, из них выяснил, что нас долбят огромным количеством спама, разобрался с iptables на уровне забанить IP. Написал простой скрипт, который парсил access-логи и выдавал IP, с которых было огромное количество запросов, потом банил вручную эти IP. В момент повышения нагрузки набаню 20-30 IP, перезагружу сервер, LA становится 10-12, все летает, успокаиваюсь. В течение недели плавно нарастает та же самая шляпа, нужно все повторять. Нашел информацию о сервисе fail2ban, установил, включил – изменений сразу не увидел и забыл про него. Со временем стал замечать, что нагрузка 8-10, боты вроде уже и не долбятся (очень много набанил вручную самых основных + на уровне Nginx настроил 403 ответ по куче юзер-агентов часто встречающихся ботов), но есть странные зависания при работе с сайтами – ходишь по страницам, отправляешь формы, и в какой-то момент бац – 10-15 секунд зависание запроса, который в 90% случаев выполняется, а в 10% отваливается после этого ожидания. Тут же пробуешь повторить действие несколько раз – все в порядке. Через 2-3 минуты опять такое же зависание, клиенты тоже начали на подобное жаловаться, и это поведение спустя полгода начало ухудшаться – уже и пару раз за минуту могло произойти. В этот момент вспомнил про fail2ban, установленный полгода назад и брошенный с настройками по умолчанию (там были включены фильтры для ssh и apache), попробовал его выключить – ситуация с зависаниями очень сильно сократилась, в день выключения заметил 3-5 подвисаний за весь день, что могло и по любым другим причинам произойти. Но! Начала опять расти нагрузка, стало 20-30, как и раньше, и подвисаний вроде и нет, но зато все медленно работает. Решил разобраться с fail2ban, выключил секцию apache, включил apache-badbots, написал для него собственную регулярку со списком постоянно спамящих нас юзер-агентов (за сутки более 600 IP по ним он забанил), также оставил секцию с ssh. Параллельно с этим просмотрел лог медленных запросов MySQL, поисправлял кучу запросов, добавил индексов (при высоком LA, как правило, именно mysqld жрал CPU сильнее всех по команде top), нагрузка спала аж до 3-5 в моменте, все начало летать. Спустя 2 дня опять начинаются подвисания по 10-15 секунд, LA 8-10. Выключил fail2ban, нагрузка 20-30, зато нет зависаний. Моментами спадает нагрузка, может 2 часа держаться в норме, потом опять 20-30. Перезагружаю Apache, нагрузка падает, в течение 10 минут опять вырастает.

Перерыл весь интернет, везде все разное, каждый случай, как я понял, в администрировании уникальный, какой-то конкретной методологии выявления проблем не нашел, хожу по кругу, 10 часов танцев с гуглом (бубном), удается снизить нагрузку, но через 2 дня опять подскоки, причем в час-пик может быть 8-10, а ночью 20, хотя чаще все-таки наоборот. И если с самой нагрузкой еще хоть какие-то наметки понятны, хотя далеко не все, то с зависаниями при включенном fail2ban не улавливаю вообще, ведь он конкретный входящий запрос не трогает – он сканит логи.

Моя логика такая, что из-за того, что на сервере в районе 100 сайтов, которых постоянно посещает куча разных ботов, которые, может, и не такие плохие, и нагрузку на каждый сайт создают небольшую, но если сайтов 100, то и нагрузка x100. Они дергают запросы, каждый запрос – нагрузка на mysql, которая все время «в топе» команды top. Их нужно банить автоматически, с чем справляется fail2ban, но после его включения через некоторое время начинаются какие-то зависания соединений. После его выключения, боты выходят из бана и начинают нас спамить, дергать огромное количество страниц, создавая огромное количество запросов к БД, которая начинает жрать все ресурсы CPU. А может это предположение, потому что в момент этой высокой нагрузки не понимаю, за что зацепиться – и боты, и MySQL жрет CPU, естественно лог медленных запросов растет, а нужно ли их исправлять – да вроде нет, ведь когда нагрузка в норме, лог почти не растет.

В общем хочу обратиться за помощью, с чего начать, чтобы не ходить по кругу от access-логов и fail2ban с iptables до оптимизации кода приложений? Уже умуздыкался, результат всегда один – через некоторое время после 1-2 дней танцев с бубном начинаются ухудшения производительности.



Последнее исправление: shell-script (всего исправлений: 1)

Вот просто интересно — ты всерьёз рассчитывал, что вот эту вот простыню без абзацев кто-то не бросит читать после первых двух предложений, не говоря уж о том, чтобы в неё вникать и, задрав штаны, бежать решать твои проблемы?

alegz ★★★★
()

Чувак, то, что ты принес — это все равно, что явится на форум строителей с вопросом: «Чуваки, я нуб в архитектуре, максимум скворечник делал в школе на уроке труда, нужно заказчику сделать проект дома на 5 спален из кирпича на песчаной почте в виде подробных чертежей и сметы материалов».

Задача явно не по плечу тебе лично даже с подсказками, и сильно выше по сложности той, что решают на форумах. Это нужно смотреть и читать логи, пробовать и вникать. То есть в Job, искать исполнителя.

И ты в курсе, что Debian 7 давно не поддерживается, и там полно эпичных дыр?: Помогите пожалуйста!! (комментарий)

Vsevolod-linuxoid ★★★★★
()

12 ядер

LA держался на уровне 25-30,

Удивительная стабильность. Это, как я понимаю, с гипертредингом, т.е. 24 логических ядра и заняты они были как раз по-максимуму. Любое превышение сразу уводит LA в бесконечность.

firkax ★★★★★
()
Последнее исправление: firkax (всего исправлений: 1)

Поправил чуть-чуть форматирование. Почитай плиз инструкцию прежде чем постить большие портянки. Никто их читать не будет без этого.

shell-script ★★★★★
()

По теме. Ты пишешь, что в топе по нагрузке mysql. Где его конфиг? Как анализировал slowlog? Где fail2ban хранит записи, тоже в мускле? Какие ошибки в логах, когда не отрабатывают запросы на сайтах? Я так и не понял, что у тебя там настроено - apache бекэндом, nginx проксирует на него? Или где-то apache, а где-то nginx+php-fpm? Или ещё как?

shell-script ★★★★★
()

на сервере в районе 100 сайтов, которых постоянно посещает куча разных ботов, которые, может, и не такие плохие … Их нужно банить автоматически

Нет. Если, например, забанить гуглбот, сайт пропадет из выдачи гугла, на сайт перестанут заходить люди, нагрузка упадет, все довольны (нет).

Нужно или сервер помощнее, или прикручивать кеширование, или оптимизировать сайты. Для второго и третьего нужен не только админ, но и веб-девелопер.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от firkax

cat /proc/cpuinfo – на каждом ядре во флагах есть «ht», означает ли это, что логических ядер 24? И если так, то в моем случае LA до 24 норма? Но при нагрузках до 12 производительность всегда одинаковая, а больше 12 сразу снижение производительности заметное. Выше 35-40 да, тормоз конкретный уже, но бывает все-таки редко.

envker
() автор топика
Ответ на: комментарий от shell-script

Apache бекэнд, Nginx прокси.

Конфиг MySQL из того, что настраивал я, остальное по умолчанию:

skip-name-resolve
performance_schema = off

innodb_flush_method = O_DIRECT
innodb_buffer_pool_size = 15G
innodb_buffer_pool_instances = 15
innodb_log_file_size = 1G
innodb_flush_log_at_trx_commit = 2
innodb_additional_mem_pool_size = 20M
secure_file_priv = ""
log_slow_queries = /var/log/mysql/mysql_slow.log
long_query_time = 5
log_error = /var/log/mysql/mysql_error.log
log_warnings = 1
max_connections = 2000
wait_timeout = 90
interactive_timeout = 90
innodb_stats_on_metadata = 0
innodb_log_buffer_size = 8M
table_definition_cache = 4096
innodb_read_io_threads = 8
innodb_write_io_threads = 8
innodb_thread_concurrency = 24

Slow-лог просто просматривал запросы, которые туда попадают, смотрел их EXPLAIN, исправлял, запросы оттуда уходили. На данный момент смотрел запросы от 5 сек, бОльшая часть из них исправлена. Также включал логирование запросов без индекса, расставлял индексы, с этим вроде ок. Там у меня остались запросы типа LOAD DATA INFILE – это загрузка больших прайс-листов, иногда с миллионами строк, их не ускорить.

До сих пор попадают туда запросы INSERT иногда довольно элементарные, но их очень много, они все на 1 таблицу от разных пользователей, допускаю наличие блокировок, еще не разбирался.

В fail2ban banaction = iptables-multiport, то есть он устанавливает правила для iptables, если я правильно понял. Во всяком случае в iptables записи попадают. Насколько я понимаю, больше он нигде ничего не хранит.

envker
() автор топика
Ответ на: комментарий от goingUp

Нет. Если, например, забанить гуглбот, сайт пропадет из выдачи гугла, на сайт перестанут заходить люди, нагрузка упадет, все довольны (нет).

Нужно или сервер помощнее, или прикручивать кеширование, или оптимизировать сайты. Для второго и третьего нужен не только админ, но и веб-девелопер.

Я и есть веб-девелопер, просто с администрированием есть проблемы, так как изучал его только в моменты, когда уже все летит в пропасть, и нужно срочно применить костыли, лишь бы клиенты угомонились =) А как только проблема устранялась хотя бы частично, сразу же продолжал заниматься разработкой, а сервер бросал.

Поисковиков естественно не блокирую, настроил фильтрацию тупо по User-agent вот таким методом в fail2ban:

badbots = babbar|serpstatbot|MJ12bot|DataForSeoBot|AhrefsBot|Konturbot|Barkrowler|MegaIndex|HonoluluBot|BLEXBot|SeekportBot|SemrushBot

failregex = ^<HOST> -.*"(GET|POST).*HTTP.*".*(?:%(badbots)s).*"$

То есть блокируем только то, что не нужно, тут лишнего не наблокируешь. В целом работает, в бан уходят все перечисленные.

envker
() автор топика
Ответ на: комментарий от shell-script

Какие ошибки в логах, когда не отрабатывают запросы на сайтах?

В логах apache/nginx ничего особенного, в каких логах еще посмотреть и на что внимание обратить? Так как большая часть запросов в итоге выполняется после 10-15 сек. подвисания, то, как я предполагаю, в логах я этого могу и не увидеть. Выглядит это так, будто скорость интернета проседает сильно, но она в норме естественно (во всяком случае у меня дома).

По команде ifconfig сегодня заметил на eth0 (сетевая карта?) кучу ошибок на входе, которые причем очень быстро прибавляются, сегодня сервер сутра перезагружал – это вот к вечеру, 15 млн ошибок.

eth0      Link encap:Ethernet  HWaddr de:6e:5e:e5:27:4d                                                                                                           
          inet addr:91.201.41.156  Bcast:91.201.41.255  Mask:255.255.255.0                                                                                        
          inet6 addr: fe80::dc6e:5eff:fee5:274d/64 Scope:Link                                                                                                     
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                                                                                                      
          RX packets:249569678 errors:15906471 dropped:1894 overruns:0 frame:15906471                                                                             
          TX packets:211639389 errors:0 dropped:0 overruns:0 carrier:0                                                                                            
          collisions:0 txqueuelen:1000                                                                                                                            
          RX bytes:194536790667 (181.1 GiB)  TX bytes:82677061604 (76.9 GiB)                                                                                      

eth0:0    Link encap:Ethernet  HWaddr de:6e:5e:e5:27:4d                                                                                                                
          inet addr:91.201.43.57  Bcast:91.201.43.57  Mask:255.255.255.255                                                                                             
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                                                                                                           

lo        Link encap:Local Loopback                                                                                                                                    
          inet addr:127.0.0.1  Mask:255.0.0.0                                                                                                                          
          inet6 addr: ::1/128 Scope:Host                                                                                                                               
          UP LOOPBACK RUNNING  MTU:16436  Metric:1                                                                                                                     
          RX packets:1256675384 errors:0 dropped:0 overruns:0 frame:0                                                                                                  
          TX packets:1256675384 errors:0 dropped:0 overruns:0 carrier:0                                                                                                
          collisions:0 txqueuelen:0                                                                                                                                    
          RX bytes:537528641852 (500.6 GiB)  TX bytes:537528641852 (500.6 GiB)

Что означает информацию не нашел, везде по-разному описано, но в связи с описанной мной проблемой обратил на это внимание.

envker
() автор топика
Ответ на: комментарий от envker

Если у тебя 12 полноценных ядер без гипертрединга, то норма до 12. Если у тебя 12 ядер с гипертредингом, итого 24 логических ядра - норма где-то до 18, и до 24 кое как сойдёт.

firkax ★★★★★
()
Ответ на: комментарий от envker

failregex = ^<HOST> -.*"(GET|POST).*HTTP.*".*(?:%(badbots)s).*"$

В качестве мааааленькой оптимизации: как минимум, вот этот вот хвост: .*"$ ничего полезного не делает, только сжирает циклы CPU. Да и вообще, полагаю, этот regexp ещё можно очень сильно оптимизировать, но надо с бенчмарками поиграть. Все эти .* скорее всего очень сильно его замедляют. (GET|POST) - почему не (?:GET|POST)? Лишние сохранения групп тоже отнимают CPU и память при выполнении.

emorozov
()
Ответ на: комментарий от envker

Ну если ты считаешь, что проблема из-за поисковых ботов, тогда во первых, сколько страниц на сайтах? Может быть такое, что на страницах какие-то мусорные гет параметры, и боты загружают их во всех вариациях, что тебе совершенно не нужно. Во-вторых, нужно кеширование. Из кеша nginx можно раздавать тысячи запросов в секунду, и плевать, боты там или не боты.

goingUp ★★★★★
()
Ответ на: комментарий от emorozov

В качестве мааааленькой оптимизации: как минимум, вот этот вот хвост: .*«$ ничего полезного не делает, только сжирает циклы CPU. Да и вообще, полагаю, этот regexp ещё можно очень сильно оптимизировать, но надо с бенчмарками поиграть. Все эти .* скорее всего очень сильно его замедляют. (GET|POST) - почему не (?:GET|POST)? Лишние сохранения групп тоже отнимают CPU и память при выполнении.

Спасибо за совет. В целом fail2ban вообще не создает нагрузку, по нулям в мониторе top.

(GET|POST) – так было по умолчанию в фильтре fail2ban, я только чуть поправил его под свои логи, иначе фильтр не срабатывал. В целом в python не силен, в php регулярки несколько отличаются, поэтому взял за основу то, что было.

envker
() автор топика
Ответ на: комментарий от goingUp

Ну если ты считаешь, что проблема из-за поисковых ботов

Я предполагаю, во всяком случае блокировка большого количества ботов снижает нагрузку, пока они опять не набегут со временем. Плюс в моменты LA 50+, как правило, обнаруживался какой-то парсер, после блокировки которого все приходило в норму, если он с ограниченного количества IP конечно долбился, которое можно заблочить вручную.

тогда во первых, сколько страниц на сайтах? Может быть такое, что на страницах какие-то мусорные гет параметры, и боты загружают их во всех вариациях, что тебе совершенно не нужно.

Сложно сказать, десятки миллионов страниц, возможно, больше сотни миллионов. С GET-параметрами с точки зрения SEO работали в свое время, страниц-дублей, как минимум, те же Яндекс.Вебмастер и Google Search Console практически никогда не находят среди всех этих страниц.

Во-вторых, нужно кеширование. Из кеша nginx можно раздавать тысячи запросов в секунду, и плевать, боты там или не боты.

Не знал, что кеш Nginx может сохранять страницы, надо попробовать, но есть нюанс. Все сайты – интернет-магазины с миллионами автозапчастей, и это такая сфера, где одну и ту же запчасть могут искать и заказывать раз в год, и есть подозрение, что кеширование будет работать впустую. А именно поиск товаров на сайте по артикулу запчасти – самое нагруженное место из того, что парсят боты. Сами результаты поиска у нас кешируются в файловой системе , чтобы не собирать их повторно хотя бы при обновлении страницы, пересортировке результатов и добавлении в корзину.

envker
() автор топика
Ответ на: комментарий от firkax

Если у тебя 12 полноценных ядер без гипертрединга, то норма до 12. Если у тебя 12 ядер с гипертредингом, итого 24 логических ядра - норма где-то до 18, и до 24 кое как сойдёт.

Подскажи, как точно определить наличие гипертрединга, и включен ли он? Также если включен, то в тех настройках сервисов, в которых подразумевается распараллеливание по ядрам (если я правильно это понимаю), стоит указывать именно 24, а не 12? Такие настройки, например, есть в MySQL и Sphinx.

envker
() автор топика
Ответ на: комментарий от Vsevolod-linuxoid

Чувак, то, что ты принес — это все равно, что явится на форум строителей с вопросом: «Чуваки, я нуб в архитектуре, максимум скворечник делал в школе на уроке труда, нужно заказчику сделать проект дома на 5 спален из кирпича на песчаной почте в виде подробных чертежей и сметы материалов».

Задача явно не по плечу тебе лично даже с подсказками, и сильно выше по сложности той, что решают на форумах. Это нужно смотреть и читать логи, пробовать и вникать. То есть в Job, искать исполнителя.

Возможно, хотя так или иначе последние 8 лет проект поддерживаю, стараюсь разбираться все время сам, много чего устанавливал и настраивал, но вот впервые обратился на форум за помощью, чтобы направили хотя бы. В целом, как раз этот форум – последняя инстанция перед наймом того, кто просто это сделает за меня. Тут проблема в том, что хочется иметь возможность самому быстро решать хотя бы не сильно сложные вопросы, а не каждый раз искать исполнителя.

И ты в курсе, что Debian 7 давно не поддерживается, и там полно эпичных дыр?

Да, это отдельное страдание, перенос так же оттягивается, потому что это дел для меня на неделю, а проект коммерческий, надо на это настроиться, подготовиться и в какую-нибудь праздничную неделю это сделать, и нигде не накосячить. Когда-нибудь я это сделаю, возможно, на ближайших майских праздниках.

envker
() автор топика
Ответ на: комментарий от envker

lscpu показывает количество сокетов, количество ядер на 1 сокет и количество тредов на 1 ядро. С гипертредингом 2 треда, без - 1.

firkax ★★★★★
()
Ответ на: комментарий от envker

В целом fail2ban вообще не создает нагрузку, по нулям в мониторе top.

Ну, я не знал. Подумал, если там 10000 RPS в секунду и приходится перелопачивать груды логов, то нагрузка может быть серьёзной.

В большей части языков, регекспы сильно не отличаются, если не лезть в дебри. И .* надо избегать в любом языке, т.к. это верный способ получить медленно работающую регулярку. Встречал в жизни ситуации, когда неоптимизированные регулярки сильно тормозили работу софта. Это было, правда 12-14 лет назад, а сейчас настолько мощные процы, что можно писать криво и косо совершенно всё - CPU прожуёт и заметно почти не будет. Ну да, в целом весь софт тормозит так же, как и раньше, но это потому что теперь везде O(n²) под капотом.

Эту регулярку можно было бы улучшать и улучшать. Но раз не в ней дело, то наверное действительно стоит сначала найти реальный источник тормозов.

emorozov
()
Ответ на: комментарий от envker

А именно поиск товаров на сайте по артикулу запчасти – самое нагруженное место из того, что парсят боты.

Поиск? Боты парсят поиск? Это сделано в целях СЕО?

В целом, мне кажется, низко висящие фрукты в плане оптимизации вы уже сорвали, может просто тупо надо сервер мощнее в связи с возросшей посещаемостью.

goingUp ★★★★★
()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от firkax

lscpu показывает количество сокетов, количество ядер на 1 сокет и количество тредов на 1 ядро. С гипертредингом 2 треда, без - 1.

1 тред на 1 ядро у меня по lscpu

envker
() автор топика
Ответ на: комментарий от goingUp

И миллион запчастей раз в год 1000000÷12÷30÷24÷60÷60 = 0,0322 rps

У тебя явно нагрузка выше.

Есть запчасти, которые ищут постоянно, например, запчасти для ТО. Но их меньшинство, и кешировать их вряд ли есть смысл. А по поводу остальных – их не миллион, а сотни миллионов в тысячах прайс-листах. В одном проекте используется Sphinx, только в нем загружено 200+ млн позиций в 1500 прайс-листах, из которых 90 млн обновляются каждый день или почти. Сколько в остальных интернет-магазинах не считал, там у каждого от десятков тысяч до десятков миллионов позиций, сайтов этих более 100, каждый из них и поисковые боты посещают, и мусорные, вот мусорных надо отсечь, с этим fail2ban справляется, как я уже писал, LA с ним падает ниже 12, даже до 6-7 (напомню, на 12 ядрах). В часы-пик может расти до 14-18, но это еще ничего, работать можно. Но по какой-то причине после нескольких дней работы fail2ban появляются зависания странные при отправке http-запросов. 20-50 запросов нормальных, потом 1 запрос на 30 секунд виснет, потом опять 2-3 минуты стабильно работает, потом опять подвисание. Выключаю fail2ban – через какое-то время зависания прекращаются.

Вообще сам fail2ban вряд ли может это делать – он тупо читает логи и пишет правила в iptables. А вот как iptables на такие зависания может влиять? Я нечто похожее по описанию тут нашел (по запросу «iptables сайт тормозит»), рекомендуют в нескольких местах прописать такое правило в iptables:

iptables -A FORWARD -p tcp --tcp-flags SYN,RST SYN -j TCPMSS  --clamp-mss-to-pmtu

Что это правило делает – не разобрался, нормального описания там не было. Возможно, fail2ban каких-то кривых правил туда наставил? Или что-то в нем настраивается, чтобы они были другими. Как я понял, iptables не только позволяет банить IP, но и какие-то настройки сетевые устанавливать (могу ошибаться).

Так же команда ifconfig у меня выводит следующее:

eth0      Link encap:Ethernet  HWaddr de:6e:5e:e5:27:4d                                                                                                                
          inet addr:91.201.41.156  Bcast:91.201.41.255  Mask:255.255.255.0                                                                                             
          inet6 addr: fe80::dc6e:5eff:fee5:274d/64 Scope:Link                                                                                                          
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                                                                                                           
          RX packets:850571396 errors:39598410 dropped:7858 overruns:0 frame:39598410                                                                                  
          TX packets:694180233 errors:0 dropped:0 overruns:0 carrier:0                                                                                                 
          collisions:0 txqueuelen:1000                                                                                                                                 
          RX bytes:672208880716 (626.0 GiB)  TX bytes:314846610539 (293.2 GiB)                                                                                         
                                                                                                                                                                       
eth0:0    Link encap:Ethernet  HWaddr de:6e:5e:e5:27:4d                                                                                                                
          inet addr:91.201.43.57  Bcast:91.201.43.57  Mask:255.255.255.255                                                                                             
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1                                                                                                           
                                                                                                                                                                       
lo        Link encap:Local Loopback                                                                                                                                    
          inet addr:127.0.0.1  Mask:255.0.0.0                                                                                                                          
          inet6 addr: ::1/128 Scope:Host                                                                                                                               
          UP LOOPBACK RUNNING  MTU:16436  Metric:1                                                                                                                     
          RX packets:4408653450 errors:0 dropped:0 overruns:0 frame:0                                                                                                  
          TX packets:4408653450 errors:0 dropped:0 overruns:0 carrier:0                                                                                                
          collisions:0 txqueuelen:0                                                                                                                                    
          RX bytes:1871977400448 (1.7 TiB)  TX bytes:1871977400448 (1.7 TiB)

я присылал сюда вывод этой команды 4 дня назад, ошибок на eth0 было тогда 15 млн из 250 млн входящих пакетов (6+%), спустя 4 дня ошибок уже 40 млн из 850 млн входящих пакетов (почти 5%), то есть стабильно 4-6% пакетов входящих с ошибками. Не здесь ли проблема? Что это за ошибки такие, на что влияют?

Так же правильно ли я понял, что каждый пакет – какой-то запрос на сервер? Если да, то вот rps получается 600 млн / 4 дня / 24 часа / 3600 сек = 1700 в секунду.

envker
() автор топика
Ответ на: комментарий от envker

Да errors определенно и есть проблема! (все они frame errors) - так не должно быть.

Смотри на железо, в частности: кабель, либо у тебя дохнет интерфейс машины/свитча/порта и т.д.

Более подробно: https://support.osnexus.com/hc/en-us/articles/360000439783-Definition-of-ifconfig-error-fields

Так же правильно ли я понял, что каждый пакет – какой-то запрос на сервер?

Не обязательно, это RX пакеты т.е. входящего трафика, каждый пакет это «кусок данных», конкретно «http запрос на сервер» может состоять из много пакетов (но не менее чем одного). Так же есть входящие пакеты которые «не запросы», на любого сервера в интернет приходит постоянный входящий паразитный траффик, типа пинги, сканы и т.д. (хотя и большинство несвязанного трафика будет далее дропаться сервером).

Из-за этих ошибок твой сервер теряет практически 39598410/850571396=~ 4.6% входящего трафика - это довольно много, неудивительно что клиентские запросы зависают и т.д.

Все errors на всех интерфейсов всегда должны быть по нулям (с исключением если когда перетыкать кабель, тогда нормально чтобы добавились несколько ошибок).

С другой стороны, большой LA не может быть связан с errors на интерфейсов - это другая несвязанная проблема (если вообще проблема).

manul91
()
Последнее исправление: manul91 (всего исправлений: 1)
Ответ на: комментарий от manul91

Сообщил в техподдержку датацентра информацию, мне ответили так:

Никаких проблем нет. Игнорируйте этот счетчик. rx_short_length_errors означает, что ядро вашего сервера отбросило слишком короткий пакет (скорее всего широковещательный пакет и он не предназначался для Вашего сервера). на профильных форумах рекомендуют сменить драйвер виртуальной машины, мы уже пробовали это делать и не на всех операционных системах это помогает. Но можем попробовать для Вашего vds

вот данные с корневой машины, никаких проблем с железом нет. На Вашем сервере виртуальный драйвер сетевой карты - там нет никаких проводов, физических носителей и сетевых адаптеров.

И привели такие результаты команд

root@kx04:~# ifconfig eth0
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
ether 00:25:90:7b:e4:f8 txqueuelen 1000 (Ethernet)
RX packets 72068117885 bytes 52768707848440 (47.9 TiB)
RX errors 0 dropped 571203 overruns 571203 frame 0
TX packets 66682068826 bytes 52740049650882 (47.9 TiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
root@client:~# ethtool -S eth0 | grep error
rx_errors: 0
tx_errors: 0
rx_length_errors: 42035675
rx_over_errors: 0
rx_crc_errors: 0
rx_frame_errors: 0
rx_missed_errors: 0
tx_aborted_errors: 0
tx_carrier_errors: 0
tx_fifo_errors: 0
tx_heartbeat_errors: 0
tx_window_errors: 0
rx_long_length_errors: 0
rx_short_length_errors: 42035675
rx_align_errors: 0
rx_csum_offload_errors: 0

Попробовал сейчас сбросить все правила iptables командой iptables -F – там осталось это:

root@client:~# iptables -L                                                                                                                                           
Chain INPUT (policy ACCEPT)                                                                                                                                            
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain FORWARD (policy ACCEPT)                                                                                                                                          
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain OUTPUT (policy ACCEPT)                                                                                                                                           
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain fail2ban-apache (0 references)                                                                                                                                   
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain fail2ban-ssh (0 references)                                                                                                                                      
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain ispmgr_allow_ip (0 references)                                                                                                                                   
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain ispmgr_allow_sub (0 references)                                                                                                                                  
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain ispmgr_deny_ip (0 references)                                                                                                                                    
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain ispmgr_deny_sub (0 references)                                                                                                                                   
target     prot opt source               destination        

Торможения продоложаются.

Интересует этот кусок:

Chain fail2ban-apache (0 references)                                                                                                                                   
target     prot opt source               destination                                                                                                                   
                                                                                                                                                                       
Chain fail2ban-ssh (0 references)                                                                                                                                      
target     prot opt source               destination     

Вроде все правила скинул, но это осталось – это какие-то хранилища правил fail2ban? Он сам выключен на данный момент, но, возможно, iptables их до сих пор использует?

envker
() автор топика
Ответ на: комментарий от envker

на профильных форумах рекомендуют сменить драйвер виртуальной машины, мы уже пробовали это делать и не на всех операционных системах это помогает. Но можем попробовать для Вашего vds … вот данные с корневой машины, никаких проблем с железом нет. На Вашем сервере виртуальный драйвер сетевой карты - там нет никаких проводов, физических носителей и сетевых адаптеров.

Так значит у вас виртуальный сервер, а не железный?? Это все меняет. Почему не сказали еще сначала???

Сообщил в техподдержку датацентра

Раз у вас виртуальный сервер - то все вопросы про тормозов - к техподдержку. Может они там cpu оверкомитят, или сторидж, или память, или сеть.

Уже то что такое количество пакетов «не для вашего сервера» приходят на ваш интерфейс, не совсем нормально/подозрительно.

Т.е. вполне возможно что проблема на уровень выше, «изнутри виртуалки» такое очень трудно диагностицировать, если вообще возможно.

С fail2ban-ом на вашем виртуальном сервере это скорее всего никак не связано, оставьте его в покое.

manul91
()
Последнее исправление: manul91 (всего исправлений: 5)
Ответ на: комментарий от manul91

Так значит у вас виртуальный сервер, а не железный?? Это все меняет. Почему не сказали еще сначала???

Я не думал, что это важно. Теперь понял, что мой SSD не только мой, но и еще чей-то, как и ядра процессора – часть общего процессора (так?), как и сетевуха, как и провод ethernet, идущий к общему серверу.

С fail2ban все ясно, просто совпала проблема с его установкой. В целом, он со своей задачей хорошо справился, LA в районе 8-10 стал после нормальной настройки, боты четко отфильтровались.

А в плане зависаний, как я понял, надо просто на выделенный переезжать, и там проблем не будет уже чужих во всяком случае?

Также они, как видно из цитаты от них, предлагали сменить драйвер виртуальной машины – имеет ли смысл это делать?

envker
() автор топика
Ответ на: комментарий от envker

Теперь понял, что мой SSD не только мой, но и еще чей-то, как и ядра процессора – часть общего процессора (так?), как и сетевуха, как и провод ethernet, идущий к общему серверу.

Все вы верно поняли. Если например, у вашего хостера ресурсы заоверкомичены (не гарантируются минимальные, а отдаются «столько сколько есть») то чужое виртуальные сервера на общей железке могут занимать/съедать общие ресурсы когда нагружены, и ваш виртуальный сервер «подвисать». Изнутри вашей виртуалки это будет «видеться» как непонятные зависоны с сети, медленность/зависонов обращений к накопителями, процессоров и т.д. И «причин» нельзя диагностировать обычными средствами «изнутри» вашей виртуалки; можно только «снаружи» на «железном» хосте где работают все виртуальные сервера как ваш.

А в плане зависаний, как я понял, надо просто на выделенный переезжать, и там проблем не будет уже чужих во всяком случае?

Правильно, на выделенной железке «чужих» не будет; и все будет в вашем контроле, и всех проблем можно в принципе нормально отследить.

На виртуальном тоже все будет нормально, если хостер отдает/разделяет гарантированные минимальные ресурсы железки для виртуальных гостей (например, гарантированный минимальный bandwidth/latency для сети и накопителях для каждого виртуального сервера, гарантированная минимальная производительность процессоров каждого виртуального сервера и т.д.). Но по описанию это не ваш случай (даже сеть не выделена как надо, если у вас на виртуальном сетевом адаптере приходят «чужие» пакеты для чужих IP адресов).

manul91
()
Последнее исправление: manul91 (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.