Оптимизация MySQL по результатам mysqltuner.pl / MySQL

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация MySQL по результатам mysqltuner.pl

25 сообщений из 50, страница 2 из 2

все

Оптимизация MySQL по результатам mysqltuner.pl

#39141340

Vladimir_Praha

Гость

при 256мб через 15 минут уже гораздо меньше количество prunes но они все равно есть

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.

-------- Performance Metrics -------------------------------------------------
[--] Up for: 16m 9s (358K q [370.232 qps], 12K conn, TX: 2B, RX: 46M)
[--] Reads / Writes: 95% / 5%
[--] Total buffers: 4.5G global + 6.6M per thread (300 max threads)
[OK] Maximum possible memory usage: 6.4G (20% of installed RAM)
[OK] Slow queries: 1% (6K/358K)
[OK] Highest usage of available connections: 19% (59/300)
[OK] Key buffer size / total MyISAM indexes: 2.0G/1.5G
[OK] Key buffer hit rate: 100.0% (634M cached / 184K reads)
[OK] Query cache efficiency: 56.1% (172K cached / 308K selects)
[!!] Query cache prunes per day: 416396
[OK] Sorts requiring temporary tables: 0% (149 temp sorts / 48K sorts)
[!!] Joins performed without indexes: 540
[!!] Temporary tables created on disk: 41% (8K on disk / 19K total)
[OK] Thread cache hit rate: 99% (61 created / 12K connections)
[OK] Table cache hit rate: 25% (3K open / 15K opened)
[OK] Open file limit used: 44% (7K/16K)
[OK] Table locks acquired immediately: 99% (154K immediate / 154K locks)
[OK] InnoDB data size / buffer pool: 1.5G/2.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Increasing the query_cache size over 128M may reduce performance
    Adjust your join queries to always utilize indexes
    Temporary table size is already large - reduce result set size
    Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
    query_cache_size (> 256M) [see warning above]
    join_buffer_size (> 4.0M, or always use indexes with joins)

Если поставлю 512 то они все равно появятся, но поменьше и попозже

...

Рейтинг:

0 / 0

02.01.2016, 00:36:36

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141342

Vladimir_Praha

Гость

вот при query_cache_size = 512M через 15 минут что тюнер показывает

-------- Performance Metrics -------------------------------------------------
[--] Up for: 15m 20s (287K q [312.220 qps], 10K conn, TX: 1B, RX: 34M)
[--] Reads / Writes: 94% / 6%
[--] Total buffers: 4.8G global + 6.6M per thread (300 max threads)
[OK] Maximum possible memory usage: 6.7G (21% of installed RAM)
[OK] Slow queries: 1% (4K/287K)
[OK] Highest usage of available connections: 11% (33/300)
[OK] Key buffer size / total MyISAM indexes: 2.0G/1.5G
[OK] Key buffer hit rate: 100.0% (565M cached / 171K reads)
[OK] Query cache efficiency: 64.2% (157K cached / 245K selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (119 temp sorts / 34K sorts)
[!!] Joins performed without indexes: 422
[!!] Temporary tables created on disk: 41% (7K on disk / 17K total)
[OK] Thread cache hit rate: 99% (33 created / 10K connections)
[OK] Table cache hit rate: 25% (3K open / 15K opened)
[OK] Open file limit used: 44% (7K/16K)
[OK] Table locks acquired immediately: 99% (101K immediate / 101K locks)
[OK] InnoDB data size / buffer pool: 1.5G/2.0G

-------- Recommendations -----------------------------------------------------
General recommendations:
Run OPTIMIZE TABLE to defragment tables for better performance
MySQL started within last 24 hours - recommendations may be inaccurate
Adjust your join queries to always utilize indexes
Temporary table size is already large - reduce result set size
Reduce your SELECT DISTINCT queries without LIMIT clauses
Variables to adjust:
join_buffer_size (> 4.0M, or always use indexes with joins)

но беда в том, что к утру все равно prunes полезут, пусть их меньше будет но будут. Думаю проведу эксперимент, поставлю 1гб и посмотрю что будет.

...

Рейтинг:

0 / 0

02.01.2016, 00:54:41

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141360

VGrey

Гость

Vladimir_Prahaвот при query_cache_size = 512M через 15 минут
...
но беда в том, что к утру все равно prunes полезут, пусть их меньше будет но будут. Думаю проведу эксперимент, поставлю 1гб и посмотрю что будет.

Vladimir_Praha , определитесь, Вам нужны красивые показатели тюнера, или быстрая работа mysql?
Еще раз повторяюсь: не смотрите на "Query cache efficiency" и "Query cache prunes per day", эти показатели были важны на системах с одним ядром. У Вас же, надеюсь, это не так?
Петр Зайцев в одном из своих выступлений говорил, что чаще всего, оптимальное значение query_cache_size меньше 128М.
Как по мне, авторитет Зайцев существенно выше Major Hayden.

...

Рейтинг:

0 / 0

02.01.2016, 09:42:44

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141377

Vladimir_Praha

Гость

VGreyVladimir_Prahaвот при query_cache_size = 512M через 15 минут
...
но беда в том, что к утру все равно prunes полезут, пусть их меньше будет но будут. Думаю проведу эксперимент, поставлю 1гб и посмотрю что будет.

Vladimir_Praha , определитесь, Вам нужны красивые показатели тюнера, или быстрая работа mysql?
Еще раз повторяюсь: не смотрите на "Query cache efficiency" и "Query cache prunes per day", эти показатели были важны на системах с одним ядром. У Вас же, надеюсь, это не так?
Петр Зайцев в одном из своих выступлений говорил, что чаще всего, оптимальное значение query_cache_size меньше 128М.
Как по мне, авторитет Зайцев существенно выше Major Hayden.

ядра четыре, я вас понял еще в первый раз но все пытался избавится от prunes но раз говорите игнорировать то буду игнорировать. Посмотрим что будет в долгосрочной перспективе.

Еще сейчас обнаружил странную деталь, сервер плавно начал грузится по ЛА а когда показатели стали жуткими я выключил демон сперва мускула, потом апача но картинка стала еще хуже:

Код: sql

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.

top - 13:17:37 up 238 days, 19:58,  1 user,  load average: 99.28, 78.45, 47.06
Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie
Cpu(s):  0.0%us,  0.1%sy,  0.0%ni, 86.8%id, 13.0%wa,  0.0%hi,  0.0%si,  0.0%st
Mem:  32703444k total, 30035752k used,  2667692k free,  3066248k buffers
Swap: 33553332k total,    22540k used, 33530792k free, 17743044k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  576 root      20   0     0    0    0 S    0  0.0   0:04.94 kworker/0:1
 1734 gitlab    20   0  846m  96m 2480 S    0  0.3 297:23.16 ruby1.9.1
14619 www-data  20   0  274m  61m 5272 D    0  0.2   0:06.12 apache2
16814 root      20   0     0    0    0 S    0  0.0   0:08.32 kworker/0:0
24779 root      20   0     0    0    0 S    0  0.0   3:04.98 kworker/2:0
26329 gitlab    20   0  943m 133m 2152 S    0  0.4 170:21.55 ruby1.9.1
28219 www-data  20   0 56732  28m 1784 S    0  0.1   2:14.73 nginx
29135 root      20   0 19392 1616 1020 R    0  0.0   0:00.61 top
    1 root      20   0  8404  716  592 S    0  0.0   2:09.98 init
    2 root      20   0     0    0    0 S    0  0.0   0:00.22 kthreadd
    3 root      20   0     0    0    0 S    0  0.0   9:13.25 ksoftirqd/0
    6 root      RT   0     0    0    0 S    0  0.0   0:26.34 migration/0
    7 root      RT   0     0    0    0 S    0  0.0   0:48.03 watchdog/0
    8 root      RT   0     0    0    0 S    0  0.0   0:32.58 migration/1
   10 root      20   0     0    0    0 S    0  0.0   5:41.47 ksoftirqd/1
   12 root      RT   0     0    0    0 S    0  0.0   0:31.40 watchdog/1
   13 root      RT   0     0    0    0 S    0  0.0   0:24.16 migration/2
   15 root      20   0     0    0    0 S    0  0.0   5:24.50 ksoftirqd/2
   16 root      RT   0     0    0    0 S    0  0.0   0:24.09 watchdog/2
   17 root      RT   0     0    0    0 S    0  0.0   0:18.74 migration/3
   19 root      20   0     0    0    0 S    0  0.0   5:18.28 ksoftirqd/3
   20 root      RT   0     0    0    0 S    0  0.0   0:22.60 watchdog/3
   21 root      RT   0     0    0    0 S    0  0.0   0:14.01 migration/4
   23 root      20   0     0    0    0 S    0  0.0   3:48.87 ksoftirqd/4
   24 root      RT   0     0    0    0 S    0  0.0   0:23.20 watchdog/4
   25 root      RT   0     0    0    0 S    0  0.0   0:15.24 migration/5
   27 root      20   0     0    0    0 S    0  0.0   4:13.30 ksoftirqd/5
   28 root      RT   0     0    0    0 S    0  0.0   0:22.77 watchdog/5
   29 root      RT   0     0    0    0 S    0  0.0   0:12.60 migration/6
   31 root      20   0     0    0    0 S    0  0.0   4:11.91 ksoftirqd/6
   32 root      RT   0     0    0    0 S    0  0.0   0:22.10 watchdog/6
   33 root      RT   0     0    0    0 S    0  0.0   0:11.38 migration/7
   35 root      20   0     0    0    0 S    0  0.0   4:10.99 ksoftirqd/7
   36 root      RT   0     0    0    0 S    0  0.0   0:22.40 watchdog/7
   37 root       0 -20     0    0    0 S    0  0.0   0:00.00 cpuset
   38 root       0 -20     0    0    0 S    0  0.0   0:00.00 khelper
   39 root      20   0     0    0    0 S    0  0.0   0:00.00 kdevtmpfs
   40 root       0 -20     0    0    0 S    0  0.0   0:00.00 netns

Что может грузить сервер так сильно? Повторюсь что mysql и apache были выключены, никаких бэкапов не работало (проверял) и больше ничего насколько я знаю на сервере не имеется, что это могло быть? И как обнаружить причину?

...

Рейтинг:

0 / 0

02.01.2016, 12:23:47

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141421

vkle

Участник

Откуда: Самара

Сообщения: 14 253

Рейтинг: 0 / 0

Вероятно, кроме мускуля и апача на сервере ещё много чего работает.
автор

Код: sql

Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie

Количество процессов сейчас стало заметно больше по сравнению с предыдущими (307-315). Обычно, на ничего не делающем сервере количество запущенных процессов не превышает сотню-полторы. Возможно, это какие-то зависшие задания, запущенные из крона. Top в таком случае мало чего покажет, посмотрите полный список процессов ps, наверняка, увидите что-то.

Может, есть смысл перезагрузить сервер, чтоб начать наблюдение "с чистого листа"?автор

Код: sql

up 238 days

...

Рейтинг:

0 / 0

02.01.2016, 15:55:29

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141437

Vladimir_Praha

Гость

vkleВероятно, кроме мускуля и апача на сервере ещё много чего работает.
автор

Код: sql

Tasks: 386 total,   1 running, 385 sleeping,   0 stopped,   0 zombie

Код: sql

up 238 days

спасибо большое, вы правы, перезапущу и попробую смотреть через ps

...

Рейтинг:

0 / 0

02.01.2016, 17:30:38

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141438

Vladimir_Praha

Гость

еще пока ковырялся в конфиге внимательно то обнаружил две строчки

table_open_cache
и
table_cache

а потом узнал что это одно и то же, просто в версии 5.13 переименовали, сейчас закомментировал одну, уже нерабочую по идее, посмотрим, если не испорчу чего :)

...

Рейтинг:

0 / 0

02.01.2016, 17:32:37

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141453

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

VGreyПетр Зайцев в одном из своих выступлений говорил, что чаще всего, оптимальное значение query_cache_size меньше 128М.
Как по мне, авторитет Зайцев существенно выше Major Hayden.
Так этот скрипт тоже выводит рекомендацию про query_cache <= 128M. Посмотрите внимательно.
Раньше не выводил, но мне кажется уже несколько лет выводит.

Все равно эти танцы с параметрами ничего вам не дадут. Они популярны, потому что все остальные меры оптимизации сложны. Про результативность ничего не говорится в многочисленных статьях и советах.

авторЕще сейчас обнаружил странную деталь, сервер плавно начал грузится по ЛА а когда показатели стали жуткими я выключил демон сперва мускула, потом апача но картинка стала еще хуже:
Теперь видно, что процессы ruby "сбесились". Ребут - неплохая идея.

...

Рейтинг:

0 / 0

02.01.2016, 19:16:17

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141523

VGrey

Гость

Vladimir_Praha , Прочесс оптимизации чего-либо, в частности, mysql, должен состоять из нескольких шагов, например:

1) Определяем цель(цели).
Например:
- максимально быстрая работа;
- минимальная нагрузка на систему;
- максимальное соответствие рекомендациям mysqltuner.
Обратите внимание, все три приведенные для примера цели могут противоречить друг дгугу. Думаю, очевидно, что максимально быстрая работа и минимальная нагрузка взаимо исключающие требования
Еще нюанс - скорее всего, целей будет несколько и нужно будет расставить приоритеты между ними. Например, минимальную нагрузку можно получить просто выключив мскул.

2) Если цели поставлены, определяемся с механизмами контроля достижения цели.
Чем, когда и в каких единицах измерять нагрузку на систему? Речь идет о нагрузке на проц, на дисковую систему, на память, еще на что?
Чем измерять быстродействие mysql? sysbench, скорость генерации страницы, наличие и количество записей в log_slow_queries, еще какой способ?

3) Измеряем текущее состояние и проверяем достижение цели. Может, у нас и так все в лучшем виде и ничего больше делать не нужно.

4) Выдвигаем предположение.
Наприер, предположение: mysql работает меделнно по причине локов в слишком большом query_cache.

5) Меняем соответствующий параметр.

6) Проверяем правильность предположения - то есть, переходим к шагу 3).

Vladimir_Praha , что Вы хотите получить от mysql? Как Вы измеряете эту хотелку? Не субьективно ли, случаем?

И последний вопрос: причина Ваших проблем точно в mysql?

...

Рейтинг:

0 / 0

03.01.2016, 09:10:04

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141808

Vladimir_Praha

Гость

VGrey,

Хороший вопрос, изначально было два сервера, но в связи с кризисом и прочими событиями с рублем один значительно прохудился и было принято решение свезти все хозяйство на один сервер. После того как перевезли 2/3 хозяйства заметили что LA с обычных 3-4 резко подскочил до 30-40 что и вызвало беспокойства и попытки выяснить где слабое место.

Так как в топе из всех процессов только мускул всегда был лидером с его 300-550% загрузкой процессора то и решения где искать слабое место собственно не было - взор пал автоматически туда. Да и остальное (апач и нгинкс не вызывали причин для беспокойства) честно говоря.

После была взята утилита mysqltuner и была предпринята попытка соответствовать ее требованиям, но в процессе обсуждений я разузнал очень много в том числе и то, что она не показатель идеальности настроек мускула, в итоге я вчера игрался с настройками кэша пытаясь его обуздать но в итоге от этих манипуляций отказался и просто слегка увеличил join_buffer_size до 24мб.

Ну и перезагрузил систему как тут советовали. В итоге на сервере порядка 200 вордпресс блогов, на каждый еще в течение сегодняшнего дня был установлен кэширующий плагин показатели следующие:

top - 02:25:00 up 4:30, 1 user, load average: 5.79, 5.55, 5.48
Tasks: 162 total, 6 running, 155 sleeping, 0 stopped, 1 zombie
Cpu(s): 34.4%us, 12.2%sy, 0.0%ni, 52.2%id, 1.1%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 32703444k total, 31806544k used, 896900k free, 2569504k buffers
Swap: 33553332k total, 3216k used, 33550116k free, 21218508k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2632 mysql 20 0 4934m 4.6g 12m S 105 14.8 518:41.60 mysqld
31002 www-data 20 0 290m 76m 7168 R 55 0.2 0:31.10 apache2
32554 www-data 20 0 0 0 0 Z 47 0.0 0:03.91 apache2 <defunct>
32544 www-data 20 0 274m 62m 6348 S 23 0.2 0:10.29 apache2
32526 www-data 20 0 266m 54m 6628 S 19 0.2 0:24.24 apache2
32530 www-data 20 0 289m 73m 5612 S 19 0.2 0:12.70 apache2
32552 www-data 20 0 265m 54m 6144 R 18 0.2 0:06.92 apache2
32556 www-data 20 0 277m 63m 5448 S 18 0.2 0:01.81 apache2
32417 www-data 20 0 276m 64m 7280 R 17 0.2 0:55.38 apache2
32549 www-data 20 0 266m 54m 5832 R 15 0.2 0:07.54 apache2
32514 www-data 20 0 283m 72m 7236 S 9 0.2 0:32.93 apache2
32550 www-data 20 0 267m 54m 5744 S 9 0.2 0:04.02 apache2
32528 www-data 20 0 276m 64m 6500 S 7 0.2 0:21.35 apache2
32448 www-data 20 0 278m 66m 6784 S 7 0.2 0:53.80 apache2
32527 www-data 20 0 275m 62m 6284 S 2 0.2 0:19.64 apache2
31876 www-data 20 0 276m 63m 7272 S 1 0.2 0:52.85 apache2
227 root 20 0 0 0 0 S 0 0.0 0:05.81 kworker/4:1
1305 redis 20 0 26212 1588 680 S 0 0.0 0:02.50 redis-server
1809 gitlab 20 0 919m 104m 2920 S 0 0.3 0:29.54 ruby1.9.1
8576 www-data 20 0 45996 17m 1824 S 0 0.1 0:06.44 nginx
8578 www-data 20 0 45920 17m 1804 S 0 0.1 0:06.52 nginx
31858 www-data 20 0 277m 63m 7288 S 0 0.2 0:48.72 apache2
32547 www-data 20 0 273m 61m 6176 S 0 0.2 0:07.81 apache2
32555 root 20 0 19120 1340 948 R 0 0.0 0:00.01 top
1 root 20 0 8404 704 668 S 0 0.0 0:01.22 init
2 root 20 0 0 0 0 S 0 0.0 0:00.00 kthreadd

еще я выяснил что для 8-ядерного процессора показатель ла 5.5 это отлично ибо по единичке идет на каждый процессор следовательно для чистоты нужно 5.5 делить на 8 чтобы получить картинку от обычного ла, так что в остальном все уже
просто замечательно и дальше просто буду мониторить состояние в долгосрочной перспективе.

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

...

Рейтинг:

0 / 0

04.01.2016, 01:28:34

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141818

vkle

Участник

Откуда: Самара

Сообщения: 14 253

Рейтинг: 0 / 0

Vladimir_Prahaизначально было два сервера, но в связи с кризисом и прочими событиями с рублем один значительно прохудился и было принято решение свезти все хозяйство на один сервер.Не понятно, что означает термин "прохудился". Аргументы про кризисы и рубли практически не влияют на работоспособность серверов. А если и влияют, то экономия на грамотных программистах и толковых админах только усугубляет ситуацию, вынуждая приобретать ещё более мощный сервер. Тут либо экономить на всём подряд и уронить, либо экономить грамотно и осторожно. Разумеется, если каждый из двух серверов был очень слабо (менее, чем на 50%) загружен до стаскивания всего хозяйства на один из них, то можно рассматривать вариант стащить всё в одно место, но с большой оглядкой.

Мне не совсем понятно ещё Ваше нежелание порыться в логе медленных запросов. Тут надо принять во внимание вот какой момент. Когда ЛА превышает количество ядер, а сами процессы долгоиграющие, то легко поставить сервер колом. Например, как уже было показано выше, на примере мускуля, за секунду в среднем отрабатывают пять запросов длительностью более двух секунд, то четырёх ядер для этого в долговременной перспективе недостаточно. Исключение - если все (или бОльшая часть) долгоиграйки работают от одного mysql-пользователя и аккуратненько встают в очередь выполнения. Если же они раскиданы по многим пользователям, то очереди не будет. В любом случае, есть смысл смотреть, кто конкретно "злоупотребляет" и принимать к нему меры. Даже, если это всего один пользователь из сотни - негоже ему одному отдавать целое процессорное ядро под его тормоза. А будет второй такой же злоупотребитель - ему второе... Иногда для исправления ситуации достаточно правильно поставить индексы.

Далее. Предположим, что на каждом из 4-ядерных серверов до перетаскивания в среднем нормально работали, скажем грубо, две сотни пользовательских процессов + сотня для всяких системных служб. Итого 300, а одно ядро должно переключаться, образно говоря, между 75 процессами, выделяя каждому из них какие-то кванты времени. После переезда количество пользовательских удвоится и в сумме будет 500, значит, на одно ядро будет приходиться уже 125 процессов. Штука в том, что переключение ядра между контекстами процессов тоже требует некоторых затрат времени. Таким образом, можно вполне нарваться на ситуацию, когда до переезда загрузка каждого сервера была менее 50%, а после переезда стала более 100%. Это очень упрощенное и грубое описание, конечно. Если упрощенно, то при неизменной очереди входящих запросов серверные процессы не будут успевать отрабатывать в приемлемый отрезок времени. Отсюда и лавинообразное возрастание ЛА возможно вполне. Ах да, ещё и благодарные пользователи, не получив в приемлемое время свою страничку, начнут F5 жмакать, отправляя дополнительные запросы...

Vladimir_Prahaеще я выяснил что для 8-ядерного процессора показатель ла 5.5 это отлично ибо по единичке идет на каждый процессорВ общем, да, для долговременной работы можно ориентироваться на такие или немного большие цифры. Конечно, в реальной жизни вполне могут быть относительно безболезненные кратковременные скачки до 15...20 (первое число в ЛА).

Vladimir_PrahaЕще есть с десяток блогов где базы больших размеров (от 500мб до 1.7гб) и сейчас я в раздумьях если сконвертировать майисам в иннодб снизит ли это нагрузку на процессор или нетЕсли размер ОЗУ позволяет держать все таблицы целиком в памяти, то можно ожидать разгрузки дискового ввода/вывода (не придётся при чтении лазить по каждому чиху на диск) и некоторой экономии на понижении времени ожидания дисковых операций. Однако, сложно сказать, действительно ли при майисаме происходит фактическое обращение к диску при выполнении запроса. Результат то может быть и из кеша запросов отдан или таблица столь популярна, что не успевает вымываться из дискового буфера. Тут надо очень тщательно анализировать перед изменением типа таблицы. Иннодб работает медленнее не просто так. :)

...

Рейтинг:

0 / 0

04.01.2016, 03:20:08

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141821

miksoft

Участник

Сообщения: 36 746

Рейтинг: 0 / 0

vkleИсключение - если все (или бОльшая часть) долгоиграйки работают от одного mysql-пользователя и аккуратненько встают в очередь выполнения.В MySQL разве есть такой механизм?

...

Рейтинг:

0 / 0

04.01.2016, 03:29:34

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141829

javajdbc

Участник

Откуда: Montreal

Сообщения: 18 207

Рейтинг: 0 / 0

...

Рейтинг:

0 / 0

04.01.2016, 04:40:34

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141831

javajdbc

Участник

Откуда: Montreal

Сообщения: 18 207

Рейтинг: 0 / 0

Vladimir_Praha,

Без контроля за инспользованием ресурсов пользователями --
вы не можете гарантировать стабильную работу системы.
Всегда найдется пользователь-умник который простейшим
кодом или запросом положит mysql, RoR, ngnix и apache2
всместе взятые.

Бороться с нагрузкой не имее контроля не просто бесполезно, но
и опасно для здоровья -- вы подставляете свой задницу
(пардон мой френч).

Контроль начинается с мониторинга расхода ресурсов.
top (htop) , mysqlturner -- неплохое начало, добавьте
mytop, iotop, monit, New Relic APM, gem install god.

Но главное -- контроль над конкретнимы аккаунатми.
Вам 10 раз уже сказали посмотрите в slow query log.
там есть юзер наме -- т.е. вы поймете кто и каким образом
ставит палки в колеса вашей большой телеге.
Разгильдяев будет не так много -- их можно просто выселить,
посадить отлучить от сервера на 15 суток -- ну на что у вас
силенок хватит.
Возможно проблему можно будет решить если стукнуть рельсой по руби
девелоперам, которые безалаберно используют дата акксесс фрейвок.

И еше вариант активного контроля -- ставьте лимит на
длину запросов -- убивать нафик все что длится более, допустим 5 секунд.
систему можно будет подстроить разрешеним конкретным юзерам
гонять длинные квери -- если докажут что им реально надо и они
полностью оптимизировали запросы.

Вы можете постить лимиты за количетво одновременных
соединений на юзера, на количество запросов на юзера в час,
убивать зависшие коннекции... если чё, вам
еше идей накидают тутошние опытные админы.

Главное -- чтоб вы начали активно контролировать систему
а не гадать на top-e...

Успехов.

...

Рейтинг:

0 / 0

04.01.2016, 05:13:48

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39141918

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

javajdbcmiksoftпропущено...
В MySQL разве есть такой механизм?

http://dev.mysql.com/doc/refman/5.7/en/user-resources.html
Так запросы в очередь не встают. Ошибка возникает. Страничка не отобразится.

Я такие темы много раз видел. Никакого толка тут не будет.
Программисту можно что-то советовать. Они воспринимают процесс как взаимодействие программ и готовы разбираться .
Бызнысмены-сеонизаторы надеются что сейчас посоветуют волшебное решение и бабло потечет.

...

Рейтинг:

0 / 0

04.01.2016, 12:44:42

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142125

vkle

Участник

Откуда: Самара

Сообщения: 14 253

Рейтинг: 0 / 0

miksoftvkleИсключение - если все (или бОльшая часть) долгоиграйки работают от одного mysql-пользователя и аккуратненько встают в очередь выполнения.В MySQL разве есть такой механизм?В чистом виде нет вроде, а на практике получается нечто вроде очереди. Насколько понимаю, это происходит по вот каким причинам. Во первых, из-за блокировок таблиц (типично, например, селект будет ждать снятия блокировки таблицы, которую установил перед выполнением апдейт). Во-вторых (тут могу ошибаться, поправьте), запросы с разных коннектов могут выполняться параллельно, но какие-то запросы отрабатывают, а заведомо тормозные впираются в блокировку той же самой таблицы, которую залочил такой же запрос от другого коннекта.

...

Рейтинг:

0 / 0

04.01.2016, 20:41:54

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142144

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

vkle, в стандартной схеме хостинга это обеспечивает nginx и apache с небольшим значением настройки MaxClients.

...

Рейтинг:

0 / 0

04.01.2016, 21:50:57

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142254

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

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

нет, это как раз и есть единственный вариант.

...

Рейтинг:

0 / 0

05.01.2016, 07:40:13

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142255

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

ScareCrowавторquery_cache_size надо ставить в НОЛЬ

а не в то, что вы там советуете.
Эта хрень только мешает и память жрёт.
перестаньте давать явно неправильные ответы.
чего тут неправильного?
нафиг эту хрень вообще нужна?
какой идиот ее придумал?
если тебе надо 200 раз один и тот же запрос делать, то данные нужно кэшировать в приложении, а не в СУБД, чтобы запрос вообще не делать 200 раз.

память в СУБД нужно на кэш данных тратить,
а не на всякую хрень.

...

Рейтинг:

0 / 0

05.01.2016, 07:46:49

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142257

MasterZiv

Участник

Откуда: Питер

Сообщения: 32 427

Рейтинг: 0 / 0

Vladimir_Praha,
еще раз нужно отметить, если еще не прозвучало, что высокая нагрузка CPU от СУБД - это хорошо, а не плохо. это значит, что СУБД имеет все данные в кешах , не висит на IO и при наличии запросов на входе достаточно эффективно работает.
С самой высокой загрузкой cpu бороться не нужно, нужно искать медленные запросы и оптимизировать их, например, создавая под них индексы.
а под это уже тут писали, как делать.

...

Рейтинг:

0 / 0

05.01.2016, 07:55:31

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142271

Vladimir_Praha

Гость

спасибо всем большое за советы, ушел в slow_logs

...

Рейтинг:

0 / 0

05.01.2016, 09:40:42

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142297

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

MasterZivScareCrowпропущено...

перестаньте давать явно неправильные ответы.
чего тут неправильного?
нафиг эту хрень вообще нужна?
какой идиот ее придумал?

Действительно, эта фича уникальна для РСУБД.
Как можно было не догадаться ее везде сделать ?

У многих окупается, что бы вы там себе не думали.

...

Рейтинг:

0 / 0

05.01.2016, 11:13:16

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142563

ScareCrow

Участник

Откуда: Белый город

Сообщения: 16 205

Рейтинг: 0 / 0

netwindMasterZivпропущено...

чего тут неправильного?
нафиг эту хрень вообще нужна?
какой идиот ее придумал?

Действительно, эта фича уникальна для РСУБД.
Как можно было не догадаться ее везде сделать ?

У многих окупается, что бы вы там себе не думали.

http://www.oracle.com/technetwork/articles/sql/11g-caching-pooling-088320.html

...

Рейтинг:

0 / 0

06.01.2016, 00:44:10

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142577

javajdbc

Участник

Откуда: Montreal

Сообщения: 18 207

Рейтинг: 0 / 0

MasterZiv...то данные нужно кэшировать в приложении, а не в СУБД...

...проблема в инвалидации кеша в момент изменении данных в базе...

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

кеширование на клиенте -- тоже полезная штука если
бизнес задача разрешает отлючится на определенное
время (ttl) от меняюшихся данных.

Говорить что одно решение лучше чем друго -- бессмыслено.
разные задачи -- разные решение.

...

Рейтинг:

0 / 0

06.01.2016, 03:29:37

| Ответить | Цитировать | Написать

Оптимизация MySQL по результатам mysqltuner.pl

#39142619

netwind

Участник

Сообщения: 14 195

Рейтинг: 0 / 0

ScareCrownetwindпропущено...

Действительно, эта фича уникальна для РСУБД.
Как можно было не догадаться ее везде сделать ?

У многих окупается, что бы вы там себе не думали.

http://www.oracle.com/technetwork/articles/sql/11g-caching-pooling-088320.html
ну вот я и говорю : как можно было только лишь через 20 лет развития oracle решиться скопировать эту фичу у mysql ?

...

Рейтинг:

0 / 0

06.01.2016, 10:24:45

| Ответить | Цитировать | Написать

25 сообщений из 50, страница 2 из 2

все

Форумы / MySQL [игнор отключен] [закрыт для гостей] / Оптимизация MySQL по результатам mysqltuner.pl

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=47&msg=39141377&tid=1832312]:	0ms
get settings:	6ms
get forum list:	14ms
check forum access:	3ms
check topic access:	3ms
track hit:	138ms
get topic data:	12ms
get forum data:	3ms
get page messages:	60ms
get tp. blocked users:	1ms
others:	230ms

total:	470ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы