Shi3A

Рейтинг
41
Регистрация
16.11.2010
daniq82:
Мне мониторинг прислал что все сервера из сети 144.76.x.x недоступны, не могу посмотреть в роботе кто где находится, он тоже еле пашет.

Есть сервер в той сети, всё хорошо у меня, я из России.

WapGraf:
Проверил из разных стран. Не наблюдаю.


1 1 ms 1 ms <1 мс DD-WRT [192.168.1.1]
2 2 ms 2 ms 2 ms x.x.x.x
3 2 ms 2 ms 2 ms y.y.y.y
4 2 ms 2 ms 2 ms z.z.z.z
5 88 ms 86 ms 88 ms 95.167.95.161
6 78 ms 74 ms 73 ms gw-rostelecom.hetzner.de [213.133.113.253]
7 88 ms * 88 ms core1.hetzner.de [213.239.245.6]
8 92 ms 92 ms 91 ms core22.hetzner.de [213.239.245.178]
9 * 78 ms 76 ms juniper4.rz19.hetzner.de [213.239.245.150]
10 92 ms * 92 ms hos-tr4.ex3k24.rz19.hetzner.de [213.239.243.234]

11 * * * Превышен интервал ожидания для запроса.
12 * * * Превышен интервал ожидания для запроса.

И дальше только звездочки...

Самое смешное, у меня и робот недоступен =) Куда писать, у кого спрашивать с этой проблемой? Причем неясно, чья проблема вообще, наших провайдеров или хецнера внутри? Ведь сайты-то доступны в некоторых регионах (из Москвы в частности) и странах.

ivtrans:
Никто не наблюдает потери пакетов в ДЦ 10, 12 ? Больше всего теряется на core12.hetzner.de

Такая же проблема, пакеты начинают теряться на gw-rostelecom.hetzner.de

Только у меня 15, 18, 19 ДЦ

Только что заметил, что nmap выдает


135/tcp filtered msrpc
136/tcp filtered profile
137/tcp filtered netbios-ns
138/tcp filtered netbios-dgm
139/tcp filtered netbios-ssn
445/tcp filtered microsoft-ds
Что, Hetzner начал фильтровать порты в борьбе с вирусней?
ramzer:
2). Нет коннекта по SSH к серверу.
В rescue смонтировал образ, подключился.
Был закоментирован порт, раскоментировал, перезапустил службу и перезагрузился, результат нулевой. Iptables никаких запретов нет.

Попробуй еще один ssh-демон запускать, вдруг кто-то его затерает или берет он неизвестно из каких конфигов

Итак, после настройки ядра и сервера mysql - БД выдержала.

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

Если в кратце подвести итог:

- mysql был поднастроен через приводившийся в этой теме mysqltuner.pl и еще в закромах у меня есть tuning-primer.sh.

- в самом ядре был прокачан стек tcp/ip, количество сокетов, выделяемой памяти и работа со swap'ом

- были поднастроены лимиты для пользователя mysql в /etc/security/limits.conf

Возможно что-то еще по мелочи, я точно не помню.

Glueon:
Highes connection usage у вас конечно высоковат ... Вы используете pconnect? wait_timeout не пробовали поменьше делать? Много ли sleep процессов висит?

pconnect нет, обычный mysql_connect

wait_timeout выставил сейчас в 15000

sleep'ов штук 7-12, не больше

'[umka:
;12151944']Скорее всего упирается в max_connections.
Через TCP будет работать медленней, чем через unix socket. Да оно тут и ни при чём скорее всего.

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

Кто-то мне сказал, что мол это только сам сервер слушает порт, а общается он все равно с базами через сокет, это так? (Я еще не гуглил такую информацию)

pupseg:
max_connections
а фак.... опередели. короче - key_buffer не нужен вам такой, query_cache побольше сделайте, только не надо максимализма, и ставить туда сразу 700М

Я это знаю :-) может быть не супер тонкости mysql, но все первичные советы по настройке уже чуть ли не наизусть помню :-)

А вот max_connections


Highest connection usage: 89% (358/400)

Да и я все же подозреваю, что не в mysql дело, именно в системе, в ядре, может быть еще где-то :-(

Итак, перевесил на 127.0.0.1.

Поднастроил сам mysql.

Еще немного пошаманил над самим сервером.

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

Вот это я щас баг словил, биллинг посчитал ex10 по 549.58 евро за штуку и флекси паки по 75.63

Всего: 166