в общем то в этом часть вопроса: где находится самая первая дверь, что бы туда посадить охранника?
Я так понимаю:
Первая дверь видна через нетстат - вход в приёмную
Вторая дверь nginx - это секретарша. Она пропускает в 3-ю дверь - apache и т.д.
Как поставить охранника перед первой дверью управляя вдс ?
и вот кстати.
В лог nginx нашлась такая строчка
157.55.35.52 - - [28/Jun/2013:14:22:40 +0400] "GET /robots.txt HTTP/1.1" 444 0 "-" "Mozilla/5.0 (compatible; bingbot/2.0; +http://www.bing.com/bingbot.htm)" "-"
а в netstate вот так
hosts.net:www msnbot-157-55-35-:34649 TIME_WAIT
получается он получил свои ноль байт, но всё равно висит?
это наверное тоже не вариант вручную убирать.---------- Добавлено 28.06.2013 в 14:26 ----------
Кажется разобрался:
Все коннекты в нетстате показывают тех, кто стоит в приёмной кабинета директора нашего завода в очереди к секретарше (TIME_WAIT) , или уже находятся в кабинете директора (ESTABLISHED).
Т.к. директору бингбот уже надоел своими завышенными требованиями, он говорит секретарше, что бы она не пускала бингбота( return 444). Но, о том, что его послали на 3 цифры он узнает только тогда, когда дождётся своей очереди.
Постоянное нахождение бингботов в списке, связано с тем, что он всё равно приходит и приходит в секунду от 3 до 5 раз. Т.е. зависания нет, есть только частое обращение. И бинг(msn)бота мы можем видеть только в состоянии TIME_WAIT.
Здесь всё понятно. Или чего то я упустил?
Выходит, что для уменьшения времени ожидания надо увеличить число допустимых коннетов к nginx (или apache ?).
В apache2.conf есть переменная MaxClients – это не она ?
логе ошибок?
/var/log/nginx/error.log
пустой
этот тоже пустой
/var/log/nginx/access.log
(правда у access.log нет даже за прошлые дни. Где то отключён ? )---------- Добавлено 28.06.2013 в 13:06 ----------
лог включил.
Вижу например это:
199.30.20.128 - - [28/Jun/2013:14:03:40 +0400] "GET /robots.txt HTTP/1.1" 444 0 "-" "msnbot-media/1.1 (+http://search.msn.com/msnbot.htm)" "-"
значит правило написано точно?---------- Добавлено 28.06.2013 в 13:07 ----------
ну, в лог nginx вижу, что сервер отдаёт 0 байт---------- Добавлено 28.06.2013 в 13:22 ----------
в netstat пишет
hosts.net:www msnbot-157-55-35-:52675 TIME_WAIT
Как отсюда узнать ip ?
Вы имеете в виду server-status подключаемы в httpd.conf строчкой
LoadModule status_module modules/mod_status.so
?
он сейчас не включён.
а другого способа нет?
не пойдёт.
Блокировка идёт до того как запрос дойдёт до апачи и .htaccess.---------- Добавлено 28.06.2013 в 12:26 ----------
если бы у msn были другие боты, то я бы их видел в аксес логе. но их там уже нет так как блокировка сама по себе работает.
Я это вижу через уменьшения нагрузки
в аксесс лог этих ботов уже нет. Если я например, уберу эту блокировку и сделаю в htaccess 503 или 404, то в аксесс логе боты появятся как посланные на 503 или 404.
в общем, названия юзер agent тут не причём я думаю---------- Добавлено 28.06.2013 в 12:35 ----------
нет такого файла на сервере
find / -name 'tcp.h' -print
-bash: include/net/tcp.h: No such file or directory
linux debian
или надо как то по особенному искать ?
Кажется я всё понял.
Всем спасибо за помощь!
так:
http://php.net/manual/en/function.ob-flush.php
пробовали?
Только сейчас дошло , что tmp_dir не имеет отношения к кешу.
точно так же как и join_buffer_size.
вот блин, перепутал ... : )
кстати, на счёт join_buffer_size: Mysql его использует для сортировок и обработок больших таблиц в памяти, а если join_buffer_size меньше чем надо, то он дозаписывает свои данные во временную папку.
Но, так как мы временную папку tmp_dir смонтировали в оперативную память, он дозаписывает эти данные тоже в оперативную память.
верно?
спасибо
1. Допустим, я выделил под mysql_tmp 512 мб. Но в системе через «# free -m» он пишет , что свободно всего 195. В этот момент mysql решил использовать смонтированную в память папку mysql_tmp. И данных у него было 300 мб.
Что он делает в этом случае?
1.1 Несмотря на нехватку памяти? пытается записать свои данные в папку.
1.2 Т.к. места нехватает он этот файл в память не пишет
1.3 В логе тут же пишет ошибку Incorrect key file for table '/mysql_tmp/#sql_2d05_0.MYI'; try to repair it
1.4 Сайт грохается и показывает ошибку error 500
Так? Или может по другому:
Видя, что не хватает памяти, он записывает не в mysql_tmp, а в какую то папку на диске. При этом посетитель сайта ошибки не замечает и всё для посетителя нормально работает?---------- Добавлено 21.06.2013 в 13:53 ----------
Я правильно понимаю?:
tmpdir смонтированный в fstab используется не для хранения закешированных запросов, а для временной записи при соединении таблиц join - ом , если не используется индекс---------- Добавлено 21.06.2013 в 13:56 ----------
хорошо : )
Спасибо netwind!
Пойду почитаю.
Есть ещё смежные вопросы:
1. На сервере несколько БД (для каждого сайта своя). Можно ли разрешить кеширование, или какой то тип кеширования для выбранных сайтов или БД? А остальные пусть без кеша живут.
2. Упомянутый мной выше способ монтирования папки в память через файл fstab «none /mysql_tmp tmpfs noexec,nosuid,size=512M 0 0» - просто указывает mysql сколько он может использовать памяти или же он эту память сразу блокирует и не даёт никому использовать?
Гугление даёт ответ на вопросы: Как настроить кеширование, как смотреть на количество закешированных запросов. Он подробно объясняет про то, что mysql хранит запросы в кеше в виде пары «запрос» «выборка данных». Про настройку переменной join_buffer_size. А вот про то, как увидеть занесённые в кеш запросы, чего то не находиться.
Вот к примеру, этот запрос :
SHOW STATUS LIKE 'Qcache%';
Говорит нам насколько эффективно используется Query Cache с текущими настройками.
Одна из переменных там, Qcache_queries_in_cache = 919, говорит нам о количестве закешированных запросов.
А вот как или где можно вытащить список из этих 919 закешированных запросов мне и нужно узнать.
Сайт на PHP, большой, много запросов, через ПХП никакой специальной работы с кешем MYSQL не ведётся.
Ну, я нигде его не прятал.
Только в fstab прописал
none /mysql_tmp tmpfs noexec,nosuid,size=512M 0 0
а в etc/mysql/my.cnf
tmpdir = /mysql_tmp
это не та самая папка, где храниться кеш запросов ? :)
Мне кажется , что нет. Но, даже если и она, то вопрос это не снимает. Когда захожу в эту папку , там ничего нет.
Если что, сервер такой .
Linux 2.6.32-028stab093.2 #1 SMP Tue Aug 23 16:27:58 MSD 2011 x86_64
Mysql - 5.1.66-0+squeeze1
Ну так, mysql его сам откуда то берёт. Может есть другой способ кроме выбрки из базы. Через пхп или команду linux или ещё как ?---------- Добавлено 21.06.2013 в 11:57 ----------
Может всё таки где то он их как бы и хранит в обычном виде тоже?
может этот хеш имеет алгоритм обратной расшифровки?
нет ли какой либо переменной в конфиге, которая включает логирование при занесении в кеш?
