Неделю назад началась котовасия - любое подключение - ssh, smtp - висит по 15-30 секунд, примерно.
Как это выглядит: putty - подключиться - login: .... ждем и только тогда запрашивает пароль.
как сказали выше - ДНС...
лечить ssh: в файле /etc/ssh/sshd_config пишем
UseDNS no
перезапускаем демон sshd
проверяем скорость подключения, если помогло, то идем ремонтировать днс :)
резолвиг днс в ssh никому не нужен, не понятно почему его не вырубили по умолчанию.
---------- Добавлено 13.12.2013 в 16:38 ----------
MrBrik: Поднят бинд. Этому серверу с таким конфигом 10+ лет и ничего не менялось.
смотрите конфиги куда бинд ходит за резолвингом, возможно вы используете "forward / forwarders" (или как-то так) к нс-ам провайдера. вот внешние нс-ы скорее всего и сдохли.
я в курсе.. но сути это не меняет. получается, что своп не системный, а mysql-ный :)
MySQL пишет на диск, если не хватает tmp_table_size.
к сожалению не все так просто с tmp_table_size... даже если хватает tmp_table_size, но во временной табличке есть хоть одно текстовое поле (text, mediumtext и т.д.) то она все-равно будет писаться на диск. также есть ограничения на размер строки и чего-то еще.
в форках Percona и MarinaDB что-то пытаются испровать, но проблема эта еще не решена.
sladkydze: 2. После этого клиент сделал рамдиск на 1 ГБ и начал скидывать туда временные таблицы MySQL, и все порешалось :) Машина перестала ацки писать на диск. Так что вот она, причина.
это костыль частично решивший проблему( что тоже хорошо ), а не причина.
причины уже назывались: отсутствие индексов, не настроенный mysql, или кривые запросы.
как я понял, оно и дальше свопится, только в рам :)
внешние вроде резолвит, а внутренние?
на .8 дать команду
nslookup 192.168.200.173
как вариант 192.168.200.173 прописать в hosts
На кронштейн приделайте, чтобы можно было опускать-поднимать и менять угол
поворотный кронштейн нужно на кровать приделывать, так глядишь и стоя спать научишься 😂
Не помогло
странно.. проверьте с каким конфигом стартует sshd, возможно он лежит где-то в /usr/local/etc/
Я уже неделю бьюсь, все что можно уже пробовал, погуглил и сделал все, что предлагают на форумах...
Еще варианты?
в одном терминале от рута запустите tcpdump с фильтром на 53 порт, и попробуйте подключится еще одним ssh
tcpdump покажет куда оно лезет и что получает в ответ.
как-то так
eth0 - замените на свой сетевой интерфейс
-v, -vv дополнительная детализация пакетов
Проанализировать реффер и по нему выводить информацию.
добавлю: проанализировать рефер - обязательно поставить куку, по куке уже выводить информацию.
а то банальный рефреш и рефера уже нет.
дешево и сердито - поднять проксик(проксики) с привязкой к ip интерфейса.
понятно, что он пропускать будет только веб трафик, но иногда и этого достаточно.
примеры проксиков: 3proxy(легкий), squid(этот может работать с несколькими аплинками).
при желании можно файрволом прозрачно заворачивать веб трафик на нужный проксик. (т.е. в браузере не нужно ничего прописывать)
Неделю назад началась котовасия - любое подключение - ssh, smtp - висит по 15-30 секунд, примерно.
Как это выглядит: putty - подключиться - login: .... ждем и только тогда запрашивает пароль.
как сказали выше - ДНС...
лечить ssh: в файле /etc/ssh/sshd_config пишем
перезапускаем демон sshd
проверяем скорость подключения, если помогло, то идем ремонтировать днс :)
резолвиг днс в ssh никому не нужен, не понятно почему его не вырубили по умолчанию.
---------- Добавлено 13.12.2013 в 16:38 ----------
Поднят бинд.
Этому серверу с таким конфигом 10+ лет и ничего не менялось.
смотрите конфиги куда бинд ходит за резолвингом, возможно вы используете "forward / forwarders" (или как-то так) к нс-ам провайдера. вот внешние нс-ы скорее всего и сдохли.
admak, оно не свопается.
я в курсе.. но сути это не меняет. получается, что своп не системный, а mysql-ный :)
к сожалению не все так просто с tmp_table_size... даже если хватает tmp_table_size, но во временной табличке есть хоть одно текстовое поле (text, mediumtext и т.д.) то она все-равно будет писаться на диск. также есть ограничения на размер строки и чего-то еще.
в форках Percona и MarinaDB что-то пытаются испровать, но проблема эта еще не решена.
Общее ощущение складывается, что ситуацию просто хотят замолчать, а все усилия направлены на уменьшение репутационных издержек.
угу, хабр уже зачистили...
почитать хабр - в кеше гугла.
2. После этого клиент сделал рамдиск на 1 ГБ и начал скидывать туда временные таблицы MySQL, и все порешалось :) Машина перестала ацки писать на диск. Так что вот она, причина.
это костыль частично решивший проблему( что тоже хорошо ), а не причина.
причины уже назывались: отсутствие индексов, не настроенный mysql, или кривые запросы.
как я понял, оно и дальше свопится, только в рам :)
Чаще происходит другое - кодеры уверены что они программисты.
угу, а программисты уверены, что они пуп земли и DBA (database administrator) не нужен... пока не ляпнется очередная чудо-база.