Тонкая настройка mysql
От: santroteam  
Дата: 30.09.03 14:30
Оценка: 29 (3)
Компилирование исходников.

Для достижения наибольшей производительности сервера нужно учитывать такие факты:

Запуск конфигуратора может иметь такой вид ( во внимание вышеизложенные факты ):
CFLAGS="-O6 -fomit-frame-pointer" \
CXX=gcc \
CXXFLAGS="-O6 -fomit-frame-pointer \
-felide-constructors -fno-exceptions -fno-rtti" \
./configure \
--enable-assembler \
--disable-shared \
--with-mysqld-ldflags="-all-static" \
--with-client-ldflags="-all-static" \
--with-unix-socket-path=/tmp/mysql.sock \
--prefix=/usr


Настройка переменных.

Если запустить mysqladmin -variables, то можно увидеть примерно такую картину.
Variable_name Value 
back_log 5 
connect_timeout  5  
basedir /usr/local/  
datadir /home/www/data/  
delayed_insert_limit 100  
delayed_insert_timeout 300  
delayed_queue_size 1000  
join_buffer  131072  
flush_time 0  
key_buffer 8388600  
language /usr/local/share/mysql/english/  
log OFF  
log_update OFF  
long_query_time 10  
low_priority_updates OFF  
max_allowed_packet 1048576  
max_connections 100  
max_connect_errors 10  
max_delayed_insert_threads 20  
max_join_size 4294967295  
max_sort_length 1024  
net_buffer_length 16384  
pid_file /usr/local/var/mysqld.pid  
port 3306  
protocol_version 10  
record_buffer 131072  
skip_locking ON  
skip_networking OFF  
socket /tmp/mysql.sock  
sort_buffer 2097144  
table_cache 64  
thread_stack 65536  
tmp_table_size 1048576  
tmpdir /tmp/  
version 3.22.27  
wait_timeout 28800


От настройки этих переменных сильно зависит производительность сервера. Надо сказать, что не существует наилучших значений для всех случаев. Для каждого конкретного сервера и поставленных задач нужно выбирать свои значения.

Рассмотрим подробнее эти переменные (......выделены наиболее важные из них ).

back_log — этот параметр показывает, сколько одновременно может быть невыполненных запросов на соединение (connection requests). Параметр имеет большое значение в тех случаях, когда к MySQL поступает ОЧЕНЬ много запросов на соединение в малый промежуток времени.

Когда к MySQL поступает connect-запрос, производятся следующие действия — проверяется, разрешен ли доступ к серверу, и если разрешен, то порождается новый процесс. Все это занимает достаточно мало времени. Однако если за это время поступит еще один connect-запрос, то он заносится в очередь. Параметр back_log определяет длину этой очереди. Если количество запросов превысит данное значение, то все непомещающиеся запросы будут игнорироваться. По умолчанию значение back_log равно 5, что вполне достаточно для большинства серверов.

Максимально значение back_log ограничено операционной системой.

connect_timeout - количество секунд, которое сервер ждет connect-пакета, по истечении этого времени будет выдан пакет " соединение ". Для более детальных разъяснений см. описание TCP/IP протокола.

delayed_insert_timeout - как долго поток INSERT DELAYED будет ожидать данных для INSERT. Более подробно значение слова DELAYED расписано в описании INSERT запроса.

delayed_insert_limit — INSERT DELAYED вставив количество записей, равное delayed_insert_limit, проверяет, есть ли SELECT-запрос к этой же таблице. Если есть, то выполняется SELECT, и только после этого продолжается INSERT.

delayed_queue_size - Для выполнения INSERT DELAYED будет выделятся очередь длиной в delayed_queue_size строк. Когда очередь заполниться все остальные конкурирующие INSERT DELAYED запросы будут ждать, пока не освободиться место в этой очереди.

flush_time - Если значение больше нуля, то каждые flush_time секунд все таблицы будут закрываться. Это позволит освобождать неиспользуемые ресурсы и синхронизировать данные на диске.

join_buffer — Величина буфера, который используется для полных JOIN запросов (.. для полного объединения двух таблиц без использования индексов ). Память под такой буфер выделяется один раз для каждого запроса. Увеличение параметра ускорит выполнение таких запросов. Более естественный путь ускорить полные JOIN запросы — использовать индексы.

key_buffer — Величина буфера ( байтах ), который используется для индексов. Этот буфер общий для всех потоков. Если используется много DELETE или INSERT запросов к таблицам с большим кол — индексов, то увеличение значения повысит скорость выполнения таких запросов. Для достижения еще большей скорости нужно использовать LOCK TABLES.

long_query_time — Если время выполнения запроса превысит данное значение ( сек.), то внутренний счетчик slow_queries будет увеличен на 1. Посмотреть значение счетчика можно командой mysql>status.

max_allowed_packet — Максимальный размер пакета для передачи данных. Данные между клиентом и сервером передаются пакетами. В начале создается пакет длиной net_buffer_length затем, если размер данных больше, то размер пакета увеличивается до необходимого значения, при этом его длина не может превысить значение max_allowed_packet. Если используются поля BLOB большого размера, то рекомендуется увеличить значение этого параметра. В идеале нужно присвоить этой переменной значение размера самого большого BLOB поля.

max_connections — Максимальное количество открытых соединений. Определяет, сколько клиентов одновременно могут работать с сервером. Увеличение параметра увеличивает количество используемых дескрипторов файла.

max_connect_errors — Если в процессе общения с клиентом произошел обрыв соединения (interrupt connection), то счетчик ошибок для хоста клиента увеличивается на 1. Когда значение этого счетчика достигнет max_connect_errors, то все последующие соединения с данного хоста будут игнорироваться. Для обнуления счетчиков использовать команду FLUSH HOSTS.

max_delayed_threads — Максимальное количество потоков, которые выполняют INSERT DELAYED. Если будет вызван запрос INSERT DELAYED, а при этом достигнуто значение max_delayed_threads, то такой запрос будет выполнен как обычный INSERT ( опции DELAYED).

max_join_size — Максимальное количество записей, которое может быть возвращено полным JOIN запросом. Если в JOIN запросе кол — записей превысит это значение, то будет возвращена ошибка. Увеличение значения этого параметра позволит выполнять большие запросы, но при этом следует учитывать, то такие запросы съедают много процессорного времени и могут содержать миллионы записей.

max_sort_length — При сортировке BLOB или TEXT полей из каждого поля берутся только первые max_sort_length байт, а остальные отбрасываются и при сортировке не учитываются.

max_tmp_tables — Максимальное количество временных таблиц, которые клиент может сохранять открытыми одновременно. На самом деле в версии 3.22 это поле ни на что не влияет.

net_buffer_length — Размер пакета для передачи данных (. max_allowed_packet) Обычно этот параметр не нужно изменять, но если у вас очень мало памяти, то его можно уменьшить до ожидаемого размера результата запроса.

record_buffer — Каждый поток, который осуществляет последовательное сканирование таблиц ( это происходит в SELECT запросах ), для каждой таблицы, участвующей в сканировании выделяет память размером record_buffer. Если будет много запросов, требующих последовательно сканировать таблицы, то значение этого параметра рекомендуется увеличить.

sort_buffer — Каждый поток, который осуществляет сортировку данных (ORDER BY или GROUP BY), выделяет память размером sort_buffer. Для повышения быстродействия запросов с ORDER BY или GROUP BY это значение необходимо увеличить.

table_cache — Количество открытых таблиц для ВСЕХ потоков. Увеличение значения приведет к увеличению количества используемых дескрипторов файла. MySQL необходимо 2 дескриптора для каждой открытой таблицы.

tmp_table_size — Максимальный размер временных таблиц. При превышении этого размера возвращается ошибка table tbl_name is full. При использовании сложных GROUP BY запросов значение нужно увеличить.

thread_stack — Размер стека для каждого потока. Обычно значение по умолчанию является достаточным.

wait_timeout — Время, которое поток ждет повторного обращения. Если за это время к потоку не было ни одного обращения, то поток убивается.

Параметры table_cache, max_connections и max_tmp_tables определяют, как много файлов сервер будет держать открытыми. Максимально количество открытых файлов для каждого процесса ограничивается операционной системой. На многих ОП это количество можно увеличить. Для более детальной информации см. руководство по вашей ОП.

table_cache зависит от max_connections. Например, если у вас 200 открытых соединений, то вам может понадобиться до 200*n открытых таблиц, где n — количество таблиц, участвующих в запросах.

MySQL при работе с таблицами использует хорошо масштабируемые алгоритмы, так что MySQL может работать даже при малых объемах памяти. Естественно для лучшей производительности нужно больше оперативной памяти.

Изменить значение настроек можно при запуске сервера опцией -O, например,
>safe_mysqld -O key_buffer=1 6M ( значениях, которые измеряются в байтах, для сокращения, можно использовать буквы К и М ).


Если у вас много памяти и много таблиц, то для увеличения производительности, при запуске сервера можно использовать такие значения.
>safe_mysqld -O key_buffer=16M -O table_cache=128 \
                -O sort_buffer=4M -O record_buffer=1M &


Если у вас мало памяти и ожидается мало соединений, то лучше сервер запускать с такими опциями
>safe_mysqld -O key_buffer=512k -O sort_buffer=100k \
          -O record_buffer=100k &


или даже
> safe_mysqld -O key_buffer=512k -O sort_buffer=16k \
          -O table_cache=32 -O record_buffer=8k -O net_buffer=1K &


Необходимо принимать во внимание, что, если сервер сконфигурировать для использования малого объема памяти, то в случае большого числа соединений может возникнуть " своппинга ", которая сильно затормозит сервер.




Как MySQL работает с памятью.
Здесь приведено описание того, как MySQL сервер работает с оперативной памятью. В скобочках жирными буквами указаны переменные, которые влияют на то или иное значение.





Как работать с таблицами для достижения большей производительности.





Форматы таблиц в MySQL

MySQL для хранения данных использует три типа таблиц: с фиксированной длиной строки, с динамической длиной строки и сжатые таблицы.

Таблицы с фиксированной длиной строки.

Таблицы с динамической длиной строки.

Сжатые таблицы.




Использование индексов.
Все индексы (PRIMARY, UNIQUE и INDEX) хранятся в B-дереве. В строковых типах автоматически происходит сжатие начальных и конечных пробелов.

Индексы используются для:

Рассмотрим следующий запрос SELECT:
SELECT * FROM tbl_name WHERE col =val AND col2=val2;


Если таблица имеет множественный индекс (col,col2), то соответствующие записи будут выбраны напрямую. Если существуют только одиночные индексы для col и col2, то оптимизатор сначала решит, при использовании какого индекса, количество возвращаемых записей будет меньше, а затем из этих записей будет произведена выборка по другому условию.

Если таблица имеет множественный индекс, то любой " префикс " этого индекса может использоваться для оптимизации запроса. Например, если есть индекс (col, col2, col3), то можно считать, что существуют индексы (col ); (col,col2); (col,col2,col3).

Любая другая часть индекса не может быть использована для оптимизации. Рассмотрим для примера такие запросы:
mysql> SELECT * FROM tbl_name WHERE col =val ;
mysql> SELECT * FROM tbl_name WHERE col2=val2;
mysql> SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;


Если есть индекс (col,col2,col3), то только в первом запросе будет использоваться индекс. Хотя второй и третий запросы содержат столбцы, которые присутствуют в индексе, но (col2) и (col2,col3) не являются левыми частями множественного индекса, и поэтому при выполнении этих запросов индекс применятся не будет.

MySQL также использует индексы для LIKE операций, если аргумент LIKE является строковой константой и при этом не начинается с символа шаблона (% или _). Например, следующие SELECT запросы используют индекс для key_col:
mysql> select * from tbl_name where key_col LIKE "Patrick%";
mysql> select * from tbl_name where key_col LIKE "Pat%_ck%";


А следующие два запроса выполняются без использования индекса:
mysql> select * from tbl_name where key_col LIKE "%Patrick%";
mysql> select * from tbl_name where key_col LIKE other_col;


В первом из этих запросов аргумент после LIKE начинается c символа шаблона, а во втором аргумент не является константой.




Общие рекомендации по повышению производительности.

Оформление моё ДХ


01.10.03 13:56: Перенесено из 'Веб программирование'
Re: Тонкая настройка mysql
От: santroteam  
Дата: 30.09.03 15:01
Оценка:
MySQL — небольшой, компактный многопоточный сервер баз данных. MySQL характеризуется большой
скоростью, устойчивостью и легкостью в использовании. MySQL был разработан компанией TcX для внутренних нужд, которые заключались в быстрой обработке очень больших баз данных. Компания утверждает, что использует MySQL с 1996 года на сервере с более чем 40 БД, которые содержат 10,000 таблиц, из которых более чем 500 имеют более 7 миллионов строк. MySQL является идеальным решением для малых и средних приложений. Исходные тексты сервера компилируются на множестве платформ. Наиболее полно возможности сервера проявляются на Unix-серверах, где есть поддержка многопоточности, что дает значительный прирост производительности. В варианте под Windows, MySQL может запускаться как сервис Windows NT или как обычный процесс на Windows 95/98. На текущий момент MySQL все еще в стадии разработки, хотя версии 3.22 полностью работоспособны.
MySQL-сервер является бесплатным для некоммерческого использования
MySQL поддерживает язык запросов SQL в стандарте ANSI 92, и кроме этого имеет множество расширений к этому стандарту, которых нет ни в одной другой СУБД.
Краткий перечень возможностей MySQL.

1. Поддерживается неограниченное количество пользователей, одновременно работающих с базой данных.
2. Количество строк в таблицах может достигать 50 млн.
3. Быстрое выполнение команд. Возможно MySQL самый быстрый сервер из существующих.
4. Простая и эффективная система безопасности.
MySQL действительно очень быстрый сервер, но для достижения этого разработчикам пришлось пожертвовать некоторыми требованиями к реляционным СУБД. В MySQL отсутствуют:
1. Поддержка вложенных запросов, типа SELECT * FROM table1 WHERE id IN (SELECT id FROM table2).
Утверждается, что такая возможность будет в версии 3.23.
2. Не реализована поддержка транзакций. Взамен предлагается использовать LOCK/UNLOCK TABLE.
3. Нет поддержки внешних (foreign) ключей.
4. Нет поддержки триггеров и хранимых процедур.
5. Нет поддержки представлений (VIEW). В версии 3.23 планируется возможность создавать представления.

По словам создателей именно пункты 2-4 дали возможность достичь высокого быстродействия. Их реализация существенно снижает скорость сервера. Эти возможности не являются критичными при создании Web-приложений, что в сочетании с высоким быстродействием и малой ценой позволило серверу приобрести большую популярность.
Re: Тонкая настройка mysql
От: santroteam  
Дата: 30.09.03 15:13
Оценка:
Я решил поднфть эту тему так как интернет развивается очень быстро а информации по ускорению MySql мало.
Re: Тонкая настройка mysql
От: santroteam  
Дата: 30.09.03 15:20
Оценка:
Ссылка на статью — http://www.hakep.h10.ru/staiya/mysql.html
Re: Тонкая настройка mysql
От: Aquary Россия https://wmspanel.com/
Дата: 01.10.03 02:13
Оценка:
Здравствуйте, santroteam, Вы писали:

Материал интересный.... но
Почему бы это не оформить в виде статьи и не выложить в соответствующий раздел сайта с предоставлением ссылки?

Так оно удобнее ИМХО...
https://wmspanel.com/nimble — Nimble Streamer media server for live and VOD HLS, RTMP, HTTP streaming
https://wmspanel.com/ — Control and reporting panel for Wowza and Nimble Streamer
http://scm-notes.blogspot.com/ — Блог об управлении конфигурацией
Re[2]: Тонкая настройка mysql
От: fidget Украина  
Дата: 01.10.03 13:28
Оценка:
Здравствуйте, santroteam, Вы писали:

S>MySQL — небольшой, компактный многопоточный сервер баз данных.


[skip]

Ну вот эта часть описания MySQL явно морально устарела года как полтора-два назад .
Re[2]: Тонкая настройка mysql
От: santroteam  
Дата: 01.10.03 13:33
Оценка:
Здравствуйте, Aquary, Вы писали:

A>Здравствуйте, santroteam, Вы писали:


A>Материал интересный.... но

A>Почему бы это не оформить в виде статьи и не выложить в соответствующий раздел сайта с предоставлением ссылки?
А где этот раздел???
Re[3]: Тонкая настройка mysql
От: Кодт Россия  
Дата: 02.10.03 09:30
Оценка:
Здравствуйте, santroteam, Вы писали:

A>>Почему бы это не оформить в виде статьи и не выложить в соответствующий раздел сайта с предоставлением ссылки?

S>А где этот раздел???

Делается так.
Сначала пишешь статью в Ворде, оформляешь ее и переводишь в XML, используя наш шаблон.
Смотри
* www.rsdn.ru/article/authors/requirements.xml
Автор(ы): The RSDN Group
Дата: 27.10.2002

* www.rsdn.ru/article/authors/template.xml
Автор(ы): Брусенцев Виталий, Чистяков Владислав Юрьевич
Дата: 22.06.2011
Статья описывает шаблон для Microsoft Word предназначенный для верстки статей и преобразования их в формат RSDN ML. В статье рассматриваются вопросы использования шаблона.


Посылаешь результат в группу — .
Статья обсуждается, и после доводки она публикуется в журнале и/или на сайте.
Перекуём баги на фичи!
 
Подождите ...
Wait...
Пока на собственное сообщение не было ответов, его можно удалить.