Евгений Русаченко: MySQL 5.1 уже как-то слишком устарел на мой взгляд
Ну так в Centos вообще почти все устарело в момент выхода. Это такая идеология дистрибутива. Зачем тогда ставить, если все равно прыгаете вперед ?
Евгений Русаченко: Подвисают именно InnoDB запросы, query_cache_size для них тоже используется? Всегда считал, что он только для MyISAM таблиц. Если да, то тогда попробую вовсе отключить, а не снижать. Если поможет - с меня какой-нибудь презент.
Кеш запросов используется независимо от движка хранения. Шансов, на мой взгляд, немного. 128 мб это не такой уж большой размер кеша.
По skip-innodb-doublewrite ситуация такова. tmp папка вынесена в оперативную память и там O_DIRECT не работает корректно, лог заваливается ошибками:
И все же, может убрать ?
вы и так от innodb_flush_log_at_trx_commit = 0 выиграете сравнительно неплохо. Некоторый перерасход памяти не так важен.
lavr7502: А если я выставляю в качестве днс 208.67.220.222 и гугл отсылает меня к сети провайдера, значит они заворачивают запрос к чужому серверу на свой?
Евгений Русаченко: ри сервера CentOS 6.6 и базами данных MySQL 5.5 (без патчей)
Начнем с того, что в centos 6.6 должен быть mysql-server-5.1.73
Вы откуда ставили mysql и как давно обновляли ?
Обычно подвисание на этапе query_end связано с очисткой кеша запросов или фиксацией транзакций.
Так что можно попробовать снизить query_cache_size = 128M .
И настройка skip-innodb-doublewrite - крайне странная. Ее никто не использует, потому что она фактически отключает нормальную фиксацию транзакций. Не исключено, что с этим и связан какой-то редкий баг.
Если хотите фиксацию хоть как-то ускорить, лучше включите innodb-doublewrite, а innodb_flush_log_at_trx_commit = 0. По крайней мере, так будет более традиционно.
ITD, надо бы модели дисков и версии прошивок огласить. Узнать можно из smartctl. Нередко с SSD так бывает, что устройство выпускается на рынок сыроватым, а хостеры их покупают еще старыми и никогда не обновляют прошивки. Что из ящика достали - то и ставят.
А лучше полностью привести вывод всех атрибутов из SMART. Там и другие возможны проблемы.
Кстати, в свежих версиях smartmontools есть база данных плохих прошивок. Там уведомление выводится. Весьма полезно.
Так в чем собственно подозревается провайдер и почему это вас не устраивает?
> 1. на картинке мы видим, что днс гугла и провайдера отдают адреса провайдера
Этой же картинке мы видим некий хост "r4---sn-pouxgn8t51-jx3l.googlevideo.com", однако не видим откуда он вообще взялся. Вы его из браузера достали. И взялся он из другой схемы распределения трафика работающей отдельно от DNS. Youtube видит IP, которым вы подключаетесь к youtube позволяет выдать вам такой URL для видеоконтента по протоколу HTTP, а не DNS.
Зная это, использовать этот хост для экспериментов и предположений о работе DNS в данном случае уже не стоит.
Но остальные эксперименты с резолвом "google.com" выглядят нормально. Никакой подмены нет :
2) вы обращаетесь на 8.8.8.8 - вам выдают ближайший к вам сервер Гугла. Он, внезапно, находится в сети провайдера. Эта сеть не помечена как принадлежащая Гуглу. Но разве это обязательно ? В этом нет ничего необычного. Как там дальше сделан туннель, где именно осуществляется обработка https - это уже дело Гугла. Снаружи же все нормально выглядит.
3) вы обращаетесь к серверу провайдера на 78.29.2.21, тот снова обращается к гуглу и ответ идентичный.
innodb_flush_log_at_trx_commit на мой взгляд не безопасно.
Так вы уже поставили 2 . Уже все. Реальные пацаны в вас пальцем будут тыкать и смеяться.
Innodb не повредится от 0, просто некоторые свежие данные могут потеряться и только лишь в случае внезапной перезагрузки.
MySQL 5.1 уже как-то слишком устарел на мой взгляд
Ну так в Centos вообще почти все устарело в момент выхода. Это такая идеология дистрибутива. Зачем тогда ставить, если все равно прыгаете вперед ?
Подвисают именно InnoDB запросы, query_cache_size для них тоже используется? Всегда считал, что он только для MyISAM таблиц. Если да, то тогда попробую вовсе отключить, а не снижать. Если поможет - с меня какой-нибудь презент.
Кеш запросов используется независимо от движка хранения. Шансов, на мой взгляд, немного. 128 мб это не такой уж большой размер кеша.
И все же, может убрать ?
вы и так от innodb_flush_log_at_trx_commit = 0 выиграете сравнительно неплохо. Некоторый перерасход памяти не так важен.
А если я выставляю в качестве днс 208.67.220.222 и гугл отсылает меня к сети провайдера, значит они заворачивают запрос к чужому серверу на свой?
Скорее, opendns отправляет в гугл обобщенную информацию о подсети клиента согласно этому документу http://tools.ietf.org/html/draft-vandergaast-edns-client-subnet-02
Но, видимо, при использовании того шифровального клиента не отправляет, поскольку предполагается, что вы от кого-то прячетесь .
ри сервера CentOS 6.6 и базами данных MySQL 5.5 (без патчей)
Начнем с того, что в centos 6.6 должен быть mysql-server-5.1.73
Вы откуда ставили mysql и как давно обновляли ?
Обычно подвисание на этапе query_end связано с очисткой кеша запросов или фиксацией транзакций.
Так что можно попробовать снизить query_cache_size = 128M .
И настройка skip-innodb-doublewrite - крайне странная. Ее никто не использует, потому что она фактически отключает нормальную фиксацию транзакций. Не исключено, что с этим и связан какой-то редкий баг.
Если хотите фиксацию хоть как-то ускорить, лучше включите innodb-doublewrite, а innodb_flush_log_at_trx_commit = 0. По крайней мере, так будет более традиционно.
ITD, соберите лучше smartmontools из исходников и обновите базу с помощью update-smart-drivedb.
Тут слишком много нераспознанных и неправильных атрибутов.
Версия прошивки вроде бы последняя. Хотя с момента выпуска этой модели SSD обновление было всего лишь одно. По народной примете этого недостаточно.
ITD, надо бы модели дисков и версии прошивок огласить. Узнать можно из smartctl. Нередко с SSD так бывает, что устройство выпускается на рынок сыроватым, а хостеры их покупают еще старыми и никогда не обновляют прошивки. Что из ящика достали - то и ставят.
А лучше полностью привести вывод всех атрибутов из SMART. Там и другие возможны проблемы.
Кстати, в свежих версиях smartmontools есть база данных плохих прошивок. Там уведомление выводится. Весьма полезно.
WapGraf, теория - так себе. За уши притянута.
При полном заполнении ребилд в риковери все равно не занимает сутки.
Очевидно, скорость ребилда в рекавери вообще не зависит от заполнения.
Ок, DNSCrypt отдаёт адреса гугла, DNS провайдера отдаёт свои, почему?
Так оба этих адреса принадлежат серверам Гугла. Это главная цель работы распределителя нагрузки использующего DNS.
В этих опытах запрос к Гуглу приходит из двух разных источников и отдаются разные ответы, которые Гугл считает ближайшими.
В случае с opendns ближайший оказывается в сети помеченной как принадлежащей Гуглу.
lavr7502, уже понятнее.
Так в чем собственно подозревается провайдер и почему это вас не устраивает?
> 1. на картинке мы видим, что днс гугла и провайдера отдают адреса провайдера
Этой же картинке мы видим некий хост "r4---sn-pouxgn8t51-jx3l.googlevideo.com", однако не видим откуда он вообще взялся. Вы его из браузера достали. И взялся он из другой схемы распределения трафика работающей отдельно от DNS. Youtube видит IP, которым вы подключаетесь к youtube позволяет выдать вам такой URL для видеоконтента по протоколу HTTP, а не DNS.
Зная это, использовать этот хост для экспериментов и предположений о работе DNS в данном случае уже не стоит.
Но остальные эксперименты с резолвом "google.com" выглядят нормально. Никакой подмены нет :
2) вы обращаетесь на 8.8.8.8 - вам выдают ближайший к вам сервер Гугла. Он, внезапно, находится в сети провайдера. Эта сеть не помечена как принадлежащая Гуглу. Но разве это обязательно ? В этом нет ничего необычного. Как там дальше сделан туннель, где именно осуществляется обработка https - это уже дело Гугла. Снаружи же все нормально выглядит.
3) вы обращаетесь к серверу провайдера на 78.29.2.21, тот снова обращается к гуглу и ответ идентичный.
http://s57.radikal.ru/i156/1503/81/daf604ebcd47.jpg
И кто все эти люди, Андрей ? кому какие IP принадлежат ? Что за программа на 127.0.0.1 обслуживает DNS ?
Как тут вообще можно что-то понять по белым буковкам без изложения мыслей ?
Это же не форум по разгадыванию шарад. Подробно объясните - вам максимум людей ответят.
А "криптование днс" это какая-то новая тантрическая практика или конкретная технология и программа ?