netwind

Рейтинг
419
Регистрация
06.05.2007
Евгений Русаченко:
innodb_flush_log_at_trx_commit на мой взгляд не безопасно.

Так вы уже поставили 2 . Уже все. Реальные пацаны в вас пальцем будут тыкать и смеяться.

Innodb не повредится от 0, просто некоторые свежие данные могут потеряться и только лишь в случае внезапной перезагрузки.

Евгений Русаченко:
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 и гугл отсылает меня к сети провайдера, значит они заворачивают запрос к чужому серверу на свой?

Скорее, 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, теория - так себе. За уши притянута.

WapGraf:
При полном заполнении ребилд в риковери все равно не занимает сутки.

Очевидно, скорость ребилда в рекавери вообще не зависит от заполнения.

lavr7502:
Ок, 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, тот снова обращается к гуглу и ответ идентичный.

lavr7502:
http://s57.radikal.ru/i156/1503/81/daf604ebcd47.jpg

И кто все эти люди, Андрей ? кому какие IP принадлежат ? Что за программа на 127.0.0.1 обслуживает DNS ?

Как тут вообще можно что-то понять по белым буковкам без изложения мыслей ?

Это же не форум по разгадыванию шарад. Подробно объясните - вам максимум людей ответят.

А "криптование днс" это какая-то новая тантрическая практика или конкретная технология и программа ?

Всего: 6293