Беспрецедентное покушение на неприкосновенность личной жизни граждан

Совет по развитию гражданского общества и правам человека при президенте РФ выступил с резкой критикой «антитеррористического» пакета законопроектов, обязывающего операторов связи три года хранить записи звонков и переписку граждан. На официальном сайте СПЧ опубликовано экспертное заключение:

…У Совета имеются основания полагать, что конечными выгодоприобретателями от действия предлагаемой нормы окажутся не правоохранительные органы, не государство, а интернет-компании, сделавшие избыточные инвестиции в центры по хранению данных, поскольку практика применения Федерального закона «О персональных данных» не позволила им заполнить достаточного количества серверных стоек…

Вспоминается, как чуть больше года назал, в преддверии оного закона, озадачился я поиском хостера в РФ. Было проведено тестирование виртуальных и полноценных серверов на десятках площадок в разных городах — ДС, ДС2 и даже в сибири. Были занятные моменты, когда обнаруживаешь свой сервер после недели работы чистым: кто-то перепутал и переставил систему. Были внезапные даунтаймы по несколько часов почти у всех хостеров. Недели стабильно не проработал ни один. Непрерывный аптайм редко у кого превышал сутки. К показателям зарубежных площадок даже рядом никто не приблизился. Бытовая железка, воткнутая в домашнего провайдера покажет более высокую стабильность.

В целом сложилось впечатление, что админы в российских серверных пьют водку, ибо холодно. Пустые бутылки кидаются в серверные стойки, коммутационные и иногда даже в силовые шкафы. А в хитросплетениях проводов возится ручной медведь. И все это действо озвучивает игрой на балалайке серб. Почему серб? Да просто так мне представляется.

Увеличение производительности mysql

Без преувеличения можно сказать что основой быстродействия mysql является наличие необходимых индексов над таблицами и наличие достаточного объема оперативной памяти для вмещения этих индексов.

Понять насколько эффективно происходит кэширование индексов в оперативной памяти можно выполнив запрос:

mysql> show status LIKE "Key%";
+------------------------+------------+
| Variable_name          | Value      |
+------------------------+------------+
| Key_blocks_not_flushed | 0          | 
| Key_blocks_unused      | 1256135    | 
| Key_blocks_used        | 458764     | 
| Key_read_requests      | 8684644670 | 
| Key_reads              | 695044     | 
| Key_write_requests     | 20732504   | 
| Key_writes             | 7800079    | 
+------------------------+------------+
7 rows in set (0.00 sec)

Соотношение показателей Key_reads (операция чтения с диска) и Key_read_requests (запросов к индексам) показывает достаточно ли отведено памяти для сохранения наиболее употребимых индексов. Соотношение 1/10000 как в этом примере свидетельствует о очень качественной работе буфера ключей. Только каждый 10000 запрос вызывает физическую операцию чтения файла индекса с диска. Если соотношение хуже чем 1/100 то нужно произвести настройку mysql для увеличения объема памяти отведенной под буферизацию индексов. Вот пример где под буфер индексов отводится 2 гигабайта памяти.

/etc/my.cnf:

[mysqld]
max_connections=500
key_buffer_size=2048M
...

Значение параметра key_buffer_size нужно подбирать исходя их объема дискового пространства занимаемого файлами индексов. В документации рекомендуется устанавливать его в размере 25% от объема RAM имеющейся на сервере. Но лучше исходить из реальной потребности конкретного сервера с конкретными базами данных и экспериментально подобрать значение дающее оптимальное соотношение показателей Key_reads / Key_read_requests.