spool писал(а): ↑04.01.2015 22:45
Или, как вариант, может это быть из-за того, что на сервер идет множество пакетов udp no cksum и bad cksum? На одном форуме писали, что эти пакеты умеет отбрасывать sysctl, но в инете инфы я не нашел. Как это можно сделать?
если пакет не фрагментирован и передается в одном фрейме, то сетевая карта сама может его проверить, снять и поставить чексумму на входящие и выходящие, и отбросить, не передавая ядру
пруф, называется TCP offload
https://en.wikipedia.org/wiki/TCP_offload_engine
http://www.wavether.com/?p=34
насколько мне известно, все новые сетевые карты это поддерживают
в таком случае, ядро ничего не получит, и никаких ошибок в логе Вы не найдете
А может у меня возникать эта проблема из-за того, что, скажем, в дата центре где-то накосячили?
мое предположение:
может быть, какой-то из каналов в ДЦ или у провайдера забился
но чтобы от предположений перейти к диагностике, нужно знать карту сети и иметь хоть какой-нибудь доступ к сетевым девайсам, минимум - проверить layer 2 от Вас до l3 коммутатора уровня аггрегирования
А почему такое странное сообщение?
я не знаю, может быть:
мы пытаемся открыть cap на запись, ядро проверяет доступные ресурсы, их нет, потому что сетевой интерфейс так говорит, потому что l2 среда может быть сильно загружена или какие другие проблемы
https://access.redhat.com/documentation/en-...eue-issues.html
spool, если честно, я ничего не понял из Ваших последних сообщений, потому что не знаю карту Вашей сети
в общем случае, все уже написали:
1. посмотрите пинг до шлюза
2. посмотрите арп таблицу после пинга
3. посмотрите ошибки на интерфейсе watch ifconfig, количество выброшенных (ошибки - это нормально, ненормально - это когда они быстро растут)
4. посмотрите потери (без ключа -f) до всех направлений, куда интересно. минимум - до шлюза. если Ваши серверы в одной L2 сети, то до соседей (тогда посмотрите ip r, или Вы можете найти соседей в арп)
5. посмотрите, может быть сопоставляется по времени
6. если есть графы трафика в ДЦ (а они точно есть, вы можете попробовать их найти), то посмотрите на них, может быть, разберетесь (но они - не повод звонить в поддержку) (если какой-то вилан перегружен, то трафик на пике будет горизонтальной прямой. не знаю, какой информацией Вы располагаете о номерах виланов и номерах интерфейсов)
7. посмотрите /var/log/messages и /var/log/audit/audit.log, и dmesg
8. посмотрите iftop -i и top
9. посмотрите на каком дуплексе договорился сетевой интерфейс
http://www.cyberciti.biz/faq/howto-setup-l...-speed-or-mode/
переключение в half duplex может временно решить и выявить ошибки в L2
10. этого можно не делать: посмотрите tcpdump, как много и какого трафика падает в интерфейс?
11. соберите и проанализируйте всю информацию из 1-10, напишите письмо в поддержку ДЦ или провайдера (кто Вам предоставляет Интернет) Если провайдер и ДЦ - это разные компании, то сначала позвоните в ДЦ с просьбой посмотреть на сервер и проверить патчкорд
и, самое главное, если это только из любопытства и не создает проблем, то лучше выпейте пива и расслабьтесь
а через несколько недель можно посмотреть еще раз, и написать какое-нибудь вежливое письмо в поддержку, приложив вывод всей диагностики (ее надо будет еще раз сразу перед письмом провести)
если это - веб сервер, то единственное, что имеет значение - это rtt и потери
если Вы находитесь в одном городе с ДЦ, то посмотрите rtt и потери с домашнего компа до сервера. также посмотрите их с retn looking glass и любых других looking glass в этом городе
если rtt низкий и потерь нет, то проблемы нет
если потери, то сформулируйте причину проблемы
это может быть "медленно открываются статичные страницы, потери до сервера" или что еще
icmp важен для установки TCP, потому что при соединении клиента происходит MTU discovery и много других интересных вещей, которым он необходим
в итоге это проявляется артефактами, например: страница открывается стразу, но не полностью, и висит, и не может до конца загрузиться - так выглядит Path MTU Discovery Black Hole
ps/ если я неправильно Вас понял, и у Вас всего один игровой сервер, которому нужен UDP, то попробуйте UDP ping
http://www.networkuptime.com/nmap/page4-6.shtml
возможно, что сам сервер кратковременно отправляет большие пачки пакетов, так что заканчивается tx queue или возникает какая другая проблема, это будет в логах
в таком случае, см. ман на RHEL, ссылку на который я выше привел
плюс нужно понимание того, что там работает, и как оно должно работать, и хорошая формулировка проблемы, и способ ее воспроизводить
это - чисто тестинг, которым Вы можете сами заняться.
провайдер сделает для Вас диагностику, если попросите, но только сети и без описания проблемы будьте готовы к ответу "на нашей стороне все работает"
или обратиться в поддержку игры. если какие-то проблемы существуют, то они не у Вас одного, они у тысяч пользователей
соответственно, в ДЦ и у провайдера знают о них, или в поддержке игры знают о них
если не знают, то проблема или в Вашем железе, или в Вашем конфиге, или в патчкорде к Вашему серверу, или в подключении - но это диагностируется провайдером очень быстро, если есть вменяемое описание проблемы и Вы предоставите ему всю поддержку с Вашей стороны. С ними можно просто обсудить, что можно сделать и будете ли Вы с ними что-то делать, или оставите как есть?
в общем, развлекайтесь) будет интересно, если Вы напишете, чем это все закончилось, так мы всем форумом немного поднимем свои знания в сетях
pps/ немного настораживает отсутствие дефолтных правил --ctstate RELATED,ESTABLISHED -j ACCEPT и -i lo -j ACCEPT, и -p icmp -j ACCEPT
может быть, это было нужно
посмотрите ss, может быть, какой-то процесс плодит петли из открытых соединений
и попробуйте iptables -F
и еще echo $http_proxy, мало ли, может действительно порутали и поставили прокси или игра поставила
