внешние вроде резолвит, а внутренние?
на .8 дать команду
nslookup 192.168.200.173
как вариант 192.168.200.173 прописать в hosts
поворотный кронштейн нужно на кровать приделывать, так глядишь и стоя спать научишься 😂
странно.. проверьте с каким конфигом стартует sshd, возможно он лежит где-то в /usr/local/etc/
в одном терминале от рута запустите tcpdump с фильтром на 53 порт, и попробуйте подключится еще одним ssh
tcpdump покажет куда оно лезет и что получает в ответ.
как-то так
tcpdump -n -ieth0 port 53 tcpdump -n -v -ieth0 port 53 tcpdump -n -vv -ieth0 port 53
eth0 - замените на свой сетевой интерфейс
-v, -vv дополнительная детализация пакетов
добавлю: проанализировать рефер - обязательно поставить куку, по куке уже выводить информацию.
а то банальный рефреш и рефера уже нет.
дешево и сердито - поднять проксик(проксики) с привязкой к ip интерфейса.
понятно, что он пропускать будет только веб трафик, но иногда и этого достаточно.
примеры проксиков: 3proxy(легкий), squid(этот может работать с несколькими аплинками).
при желании можно файрволом прозрачно заворачивать веб трафик на нужный проксик. (т.е. в браузере не нужно ничего прописывать)
как сказали выше - ДНС...
лечить ssh: в файле /etc/ssh/sshd_config пишем
UseDNS no
перезапускаем демон sshd
проверяем скорость подключения, если помогло, то идем ремонтировать днс :)
резолвиг днс в ssh никому не нужен, не понятно почему его не вырубили по умолчанию.---------- Добавлено 13.12.2013 в 16:38 ----------
смотрите конфиги куда бинд ходит за резолвингом, возможно вы используете "forward / forwarders" (или как-то так) к нс-ам провайдера. вот внешние нс-ы скорее всего и сдохли.
я в курсе.. но сути это не меняет. получается, что своп не системный, а mysql-ный :)
к сожалению не все так просто с tmp_table_size... даже если хватает tmp_table_size, но во временной табличке есть хоть одно текстовое поле (text, mediumtext и т.д.) то она все-равно будет писаться на диск. также есть ограничения на размер строки и чего-то еще.
в форках Percona и MarinaDB что-то пытаются испровать, но проблема эта еще не решена.
угу, хабр уже зачистили...
почитать хабр - в кеше гугла.
это костыль частично решивший проблему( что тоже хорошо ), а не причина.
причины уже назывались: отсутствие индексов, не настроенный mysql, или кривые запросы.
как я понял, оно и дальше свопится, только в рам :)
угу, а программисты уверены, что они пуп земли и DBA (database administrator) не нужен... пока не ляпнется очередная чудо-база.
