Нужна помощь - периодически лочится Mysql 5.5.34

227 views
Skip to first unread message

Viacheslav Romanov

unread,
Oct 12, 2014, 11:48:32 AM10/12/14
to moscow-mysq...@googlegroups.com
В различное время при высокой нагрузке происходит deadlock. Уверен что именно лок, так как mysql работает всегда стабильно, с далекими от пиковых значений параметрами (loadavg и тд), а в момент лока запись на диск практически останавливается.

В текущее время вся база (порядка 80GB) в памяти (inno_db_buffer_pool = 200G), и сервер только пишет на диски (~30-40 MB/sec в пиковое время).

Все запросы примерно такие:
1) select * from users where userId = 222;
2) update users set name='dfdf' where userId = 333;
3) insert into users values (444, 'hello')

В аттаче вывод SHOW ENGINE INNODB STATUS и SHOW PROCESSLIST в момент двух последних дэдлоков
log_10_12_12.igG
log_10_11_14.2iY

Konstantin Osipov

unread,
Oct 12, 2014, 3:27:59 PM10/12/14
to moscow-mysq...@googlegroups.com
* Viacheslav Romanov <rvv...@gmail.com> [14/10/12 23:06]:
> В различное время при высокой нагрузке происходит deadlock. Уверен что
> именно лок, так как mysql работает всегда стабильно, с далекими от пиковых
> значений параметрами (loadavg и тд), а в момент лока запись на диск
> практически останавливается.
>
> В текущее время вся база (порядка 80GB) в памяти (inno_db_buffer_pool =
> 200G), и сервер только пишет на диски (~30-40 MB/sec в пиковое время).
>
> Все запросы примерно такие:
>
> 1) select * from users where userId = 222;
> 2) update users set name='dfdf' where userId = 333;
> 3) insert into users values (444, 'hello')

приведите пожалуйста текст ошибки.


--
http://tarantool.org - an efficient, extensible in-memory data store

Viacheslav Romanov

unread,
Oct 12, 2014, 6:13:57 PM10/12/14
to moscow-mysq...@googlegroups.com
Не понял - что имеется в виду? В аттаче SHOW ENGINE INNODB STATUS\G

Viacheslav Romanov

unread,
Oct 12, 2014, 9:54:55 PM10/12/14
to moscow-mysq...@googlegroups.com
В /var/log/mysql/error.log ошибок нет, но есть странные строчки с обрывом debian-sys-maint:

141011 14:23:38 [Warning] Aborted connection 630459 to db: 'unconnected' user: 'debian-sys-maint' host: 'localhost' (Got an error writing communication packets)


По времени иногда точно совпадает - это просто отваливается в этот момент все, или это из-за debian-sys-maint проблемы возможны? 

Konstantin Osipov

unread,
Oct 13, 2014, 3:23:04 AM10/13/14
to moscow-mysq...@googlegroups.com
* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 02:34]:
> > > В различное время при высокой нагрузке происходит deadlock.
> > приведите пожалуйста текст ошибки.
> Не понял - что имеется в виду? В аттаче SHOW ENGINE INNODB STATUS\G

Какой текст ошибки выдаёт сервер при дедлоке?

show status = это доп. информация.

Konstantin Osipov

unread,
Oct 13, 2014, 3:35:56 AM10/13/14
to moscow-mysq...@googlegroups.com
* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 11:22]:
> В /var/log/mysql/error.log ошибок нет, но есть странные строчки с обрывом
> debian-sys-maint:
>
> 141011 14:23:38 [Warning] Aborted connection 630459 to db: 'unconnected'
> user: 'debian-sys-maint' host: 'localhost' (Got an error writing
> communication packets)

Это похоже на крэш а не на дедлок. Точно дедлок? Может корка
где-то лежит?

Viacheslav Romanov

unread,
Oct 13, 2014, 3:37:16 AM10/13/14
to moscow-mysq...@googlegroups.com
Нет текста ошибки при дедлоке. А корка что такое?

Konstantin Osipov

unread,
Oct 13, 2014, 5:01:20 AM10/13/14
to moscow-mysq...@googlegroups.com
* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 12:23]:
> Нет текста ошибки при дедлоке. А корка что такое?

А как вы узнаёте о них? только по innodb status?

Sveta Smirnova

unread,
Oct 13, 2014, 8:05:03 AM10/13/14
to moscow-mysq...@googlegroups.com
Привет!

On 10/13/2014 10:23 AM, Konstantin Osipov wrote:
> * Viacheslav Romanov<rvv...@gmail.com> [14/10/13 02:34]:
>>>> В различное время при высокой нагрузке происходит deadlock.
>>> приведите пожалуйста текст ошибки.
>> Не понял - что имеется в виду? В аттаче SHOW ENGINE INNODB STATUS\G
> Какой текст ошибки выдаёт сервер при дедлоке?
>
> show status = это доп. информация.
>
Костя, по-моему, речь о скрытом дедлоке. То есть о таком, который
InnoDB само не выявляет и пользователь ошибок не получает. Или, строго
говоря, не о дедлоке вообще, а о длинном локе.

Вячеслав, я правильно понимаю, что выполнение транзакций "зависает" либо
на очень долгое время, либо до момента отключения клиента по timeout?
Включите ещё InnoDB lock monitor и повторите вывод SHOW ENGINE INNODB
STATUS: там будет информация о том, какие конкретно строки залочены.

Света.

Viacheslav Romanov

unread,
Oct 13, 2014, 12:00:36 PM10/13/14
to moscow-mysq...@googlegroups.com
Привет!

Да, речь видимо о длинном локе. Спасаюсь тем, что киляю все текущие процессы (иногда по несколько раз приходится).

Логирование CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;  включил, в следующий раз упадет - покажу логи.

Сегодня ночью переключал на новый сервер с 4 ssd v5.3.38, надеюсь что вообще не упадет больше - ну или хотя бы пореже ))

Database changed

mysql> CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;

Query OK, 0 rows affected (0.01 sec)


mysql> select version();

+-----------------------------+

| version()                   |

+-----------------------------+

| 5.5.38-0ubuntu0.14.04.1-log |

+-----------------------------+

1 row in set (0.00 sec)


Viacheslav Romanov

unread,
Oct 13, 2014, 12:03:31 PM10/13/14
to moscow-mysq...@googlegroups.com
Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.

Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.

Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)

Sveta Smirnova

unread,
Oct 13, 2014, 12:05:59 PM10/13/14
to moscow-mysq...@googlegroups.com
Привет!


On 10/13/2014 07:00 PM, Viacheslav Romanov wrote:
Привет!

Да, речь видимо о длинном локе. Спасаюсь тем, что киляю все текущие процессы (иногда по несколько раз приходится).

Логирование CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;  включил, в следующий раз упадет - покажу логи.
Нет, не просто монитор, а lock monitor: CREATE TABLE innodb_lock_monitor (a INT) ENGINE=INNODB;

Сегодня ночью переключал на новый сервер с 4 ssd v5.3.38, надеюсь что вообще не упадет больше - ну или хотя бы пореже ))

Database changed

mysql> CREATE TABLE innodb_monitor (a INT) ENGINE=INNODB;

Query OK, 0 rows affected (0.01 sec)


mysql> select version();

+-----------------------------+

| version()                   |

+-----------------------------+

| 5.5.38-0ubuntu0.14.04.1-log |

+-----------------------------+

1 row in set (0.00 sec)



On Monday, October 13, 2014 6:05:03 PM UTC+6, svetasmirnova wrote:
--

---
Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.
Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Viacheslav Romanov

unread,
Oct 13, 2014, 12:12:40 PM10/13/14
to moscow-mysq...@googlegroups.com
Поправил - но че-то не видно в error.log разницы сильно)
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user-group+unsub...@googlegroups.com.

Viacheslav Romanov

unread,
Oct 13, 2014, 12:46:10 PM10/13/14
to moscow-mysq...@googlegroups.com
Ну и собственно что и ожидалось - упало прямо сейчас

SHOW ENGINE INNODB STATUS & SHOW PROCESSLIST в аттаче
newlog.txt

Sergey Bezrukov

unread,
Oct 13, 2014, 2:29:10 PM10/13/14
to moscow-mysq...@googlegroups.com
Вопрос конечно отвлечённый, но есть ли вообще смысл в персистенсе таблицы `odgems`.`sessionIds_2` ?  Может эту информацию того-с, в memcached или иной какой Redis?

--
WBR,
Serge.

13.10.2014 20:46, Viacheslav Romanov пишет:
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.

Viacheslav Romanov

unread,
Oct 14, 2014, 12:10:32 AM10/14/14
to moscow-mysq...@googlegroups.com
Да конечно sessionIds нет смысла именно в mysql хранить, а не в memcached. С другой стороны и наоборот не особо выгоднее, надо отдельный поднимать сервер и тд

В целом идея такая что есть 3 таблицы sessionIds_0 sessionIds_1 и sessionIds_2 - в них хранятся сессии, таблицы ротируются по времени, старые дропаются.
Кроме сессий также (ротация по времени с удалением старых) работают жизни, различные уведомления и тд

Slach

unread,
Oct 14, 2014, 12:29:53 AM10/14/14
to moscow-mysq...@googlegroups.com
Насколько я понял по последнему лог файлу
там куча тредов в таком состоянии

--Thread 139795399268096 has waited at row0ins.c line 2027 for 3.00 seconds the semaphore:
X-lock on RW-latch at 0x7f2774ece8c0 created in file buf0buf.c line 938
a writer (thread id 139785327740672) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0sel.c line 3908
Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/row/row0upd.c line 2144

это значит что innodb_lock_monitor не включен или что включен?
Народ, подскажите пожалуйста?

это все может быть потому что какой то flush на диск переводит innodb в какой то sync режим?
если да то какой

Вячеслав, скиньте сюда в тред пожалуйста
SHOW VARIABLES LIKE '%innodb%'; ?

и еще судя по тому что большое кол-во NULL в SHOW PROCESS LIST
может все таки попробовать заменить mysql_pconnect на mysql_connect?

Viacheslav Romanov

unread,
Oct 14, 2014, 1:04:50 AM10/14/14
to moscow-mysq...@googlegroups.com

Насколько я понял по всем логам проблема тут:


--Thread 139785057793792 has waited at btr0cur.c line 536 for 0.00 seconds the semaphore:

S-lock on RW-latch at 0x7f22dc0c0278 created in file dict0dict.c line 1843

a writer (thread id 139785486698240) has reserved it in mode  wait exclusive

number of readers 171, waiters flag 1, lock_word: ffffffffffffff55

Last time read locked in file btr0cur.c line 536

Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/btr/btr0cur.c line 529

--Thread 139785184839424 has waited at trx0trx.c line 1684 for 0.00 seconds the semaphore:

Mutex at 0x7f645163a288 created file srv0srv.c line 1024, lock var 1

waiters flag 1

--Thread 139785196480256 has waited at btr0cur.c line 536 for 2.00 seconds the semaphore:

S-lock on RW-latch at 0x7f22dc0c0278 created in file dict0dict.c line 1843

a writer (thread id 139785486698240) has reserved it in mode  wait exclusive

number of readers 171, waiters flag 1, lock_word: ffffffffffffff55

Last time read locked in file btr0cur.c line 536


On Tuesday, October 14, 2014 10:29:53 AM UTC+6, Slach wrote:
Насколько я понял по последнему лог файлу
там куча тредов в таком состоянии

--Thread 139795399268096 has waited at row0ins.c line 2027 for 3.00 seconds the semaphore:
X-lock on RW-latch at 0x7f2774ece8c0 created in file buf0buf.c line 938
a writer (thread id 139785327740672) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0sel.c line 3908
Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/row/row0upd.c line 2144

это значит что innodb_lock_monitor не включен или что включен?
Народ, подскажите пожалуйста? 

это все может быть потому что какой то flush на диск переводит innodb в какой то sync режим?
если да то какой

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

Вячеслав, скиньте сюда в тред пожалуйста
SHOW VARIABLES LIKE '%innodb%'; ?

mysql> show variables like '%innodb%';

+---------------------------------+------------------------+

| Variable_name                   | Value                  |

+---------------------------------+------------------------+

| have_innodb                     | YES                    |

| ignore_builtin_innodb           | OFF                    |

| innodb_adaptive_flushing        | ON                     |

| innodb_adaptive_hash_index      | ON                     |

| innodb_additional_mem_pool_size | 134217728              |

| innodb_autoextend_increment     | 1000                   |

| innodb_autoinc_lock_mode        | 1                      |

| innodb_buffer_pool_instances    | 1                      |

| innodb_buffer_pool_size         | 257698037760           |

| innodb_change_buffering         | all                    |

| innodb_checksums                | ON                     |

| innodb_commit_concurrency       | 0                      |

| innodb_concurrency_tickets      | 500                    |

| innodb_data_file_path           | ibdata1:10M:autoextend |

| innodb_data_home_dir            |                        |

| innodb_doublewrite              | ON                     |

| innodb_fast_shutdown            | 1                      |

| innodb_file_format              | Antelope               |

| innodb_file_format_check        | ON                     |

| innodb_file_format_max          | Antelope               |

| innodb_file_per_table           | OFF                    |

| innodb_flush_log_at_trx_commit  | 0                      |

| innodb_flush_method             |                        |

| innodb_force_load_corrupted     | OFF                    |

| innodb_force_recovery           | 0                      |

| innodb_io_capacity              | 3000                   |

| innodb_large_prefix             | OFF                    |

| innodb_lock_wait_timeout        | 50                     |

| innodb_locks_unsafe_for_binlog  | OFF                    |

| innodb_log_buffer_size          | 33554432               |

| innodb_log_file_size            | 536870912              |

| innodb_log_files_in_group       | 2                      |

| innodb_log_group_home_dir       | ./                     |

| innodb_max_dirty_pages_pct      | 75                     |

| innodb_max_purge_lag            | 0                      |

| innodb_mirrored_log_groups      | 1                      |

| innodb_old_blocks_pct           | 37                     |

| innodb_old_blocks_time          | 0                      |

| innodb_open_files               | 300                    |

| innodb_print_all_deadlocks      | OFF                    |

| innodb_purge_batch_size         | 20                     |

| innodb_purge_threads            | 0                      |

| innodb_random_read_ahead        | OFF                    |

| innodb_read_ahead_threshold     | 56                     |

| innodb_read_io_threads          | 4                      |

| innodb_replication_delay        | 0                      |

| innodb_rollback_on_timeout      | OFF                    |

| innodb_rollback_segments        | 128                    |

| innodb_spin_wait_delay          | 6                      |

| innodb_stats_method             | nulls_equal            |

| innodb_stats_on_metadata        | ON                     |

| innodb_stats_sample_pages       | 8                      |

| innodb_strict_mode              | OFF                    |

| innodb_support_xa               | OFF                    |

| innodb_sync_spin_loops          | 30                     |

| innodb_table_locks              | ON                     |

| innodb_thread_concurrency       | 0                      |

| innodb_thread_sleep_delay       | 10000                  |

| innodb_use_native_aio           | ON                     |

| innodb_use_sys_malloc           | ON                     |

| innodb_version                  | 5.5.38                 |

| innodb_write_io_threads         | 4                      |

+---------------------------------+------------------------+

62 rows in set (0.00 sec)

Sveta Smirnova

unread,
Oct 15, 2014, 8:11:46 AM10/15/14
to moscow-mysq...@googlegroups.com
Привет!


On 10/13/2014 07:46 PM, Viacheslav Romanov wrote:
Ну и собственно что и ожидалось - упало прямо сейчас

SHOW ENGINE INNODB STATUS & SHOW PROCESSLIST в аттаче


В общем проблем блокировок строк я тут не вижу или вы очень быстро убиваете ожидающие процессы. В случае проблем блокировок, дедлоков и т.п. в списке TRANSACTIONS как правило есть транзакции, которые работают по несколько секунд (больше, чем среднее) и держат лок. У вас же наиболее долгоиграющие в статусе "starting index read" и есть несколько в "sending data" и "updating" (те могут ждать локов/держать локи на самом деле, но они бы были в этом статусе сильно больше, чем в среднем по процесслисту).

Спящие процессы в статусе "transaction not started" и, по идее, держать блокировок на уровне InnoDB не должны.

Пришлите вывод SHOW CREATE TABLE users и конфигурационный файл: посмотрим, почему так много транзакций в статусе "starting index read".

Света.

On Monday, October 13, 2014 10:12:40 PM UTC+6, Viacheslav Romanov wrote:
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user...@googlegroups.com.

Sveta Smirnova

unread,
Oct 15, 2014, 8:16:15 AM10/15/14
to moscow-mysq...@googlegroups.com
Привет!


On 10/14/2014 07:29 AM, Slach wrote:
Насколько я понял по последнему лог файлу
там куча тредов в таком состоянии

--Thread 139795399268096 has waited at row0ins.c line 2027 for 3.00 seconds the semaphore:
X-lock on RW-latch at 0x7f2774ece8c0 created in file buf0buf.c line 938
a writer (thread id 139785327740672) has reserved it in mode  exclusive
number of readers 0, waiters flag 1, lock_word: 0
Last time read locked in file row0sel.c line 3908
Last time write locked in file /build/buildd/mysql-5.5-5.5.38/storage/innobase/row/row0upd.c line 2144

это значит что innodb_lock_monitor не включен или что включен?
Народ, подскажите пожалуйста?

Нет, информация по семафорам к innodb_lock_monitor отношения не имеет. Если бы он был включён, по каждой транзакции была бы распечатка типа этой:

­­­TRANSACTION 0 26244357, ACTIVE 1 sec,
OS thread id 101357568 starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 320, 1 row lock(s)
MySQL thread id 217, query id 95 localhost root Updating
update t set a=36 where a=6
TRX HAS BEEN WAITING 1 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 349 page no 3 n bits 88
index `PRIMARY` of table `test`.`t`
trx id 0 26244357 lock_mode X locks rec
but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 3;
compact format; info bits 32
0: len 4; hex 00000006; asc
;; 1: len 6; hex 000001907504; asc
u ;; 2:
len 7; hex 0000000032081c; asc
2 ;;
­­­­­­­­­­­­­­­­­­
TABLE LOCK table `test`.`t` trx id 0 26244357
lock mode IX
RECORD LOCKS space id 349 page no 3 n bits 88
index `PRIMARY` of table `test`.`t`
trx id 0 26244357 lock_mode X locks rec
but not gap waiting
Record lock, heap no 6 PHYSICAL RECORD: n_fields 3;
compact format; info bits 32
0: len 4; hex 00000006; asc
;; 1: len 6; hex 000001907504; asc
U ;; 2:
len 7; hex 0000000032081c; asc
2 ;;

­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­­TRANSACTION 0 26244356, ACTIVE 6 sec,
OS thread id 101099008
2 lock struct(s), heap size 320, 1 row lock(s),
undo log entries 2
MySQL thread id 184, query id 93 localhost root
TABLE LOCK table `test`.`t` trx id 0 26244356
lock mode IX
RECORD LOCKS space id 349 page no 3 n bits 88
index `PRIMARY` of table `test`.`t`
trx id 0 26244356 lock_mode X locks rec but not gap
Record lock, heap no 6 PHYSICAL RECORD: n_fields 3;
compact format; info bits 32
0: len 4; hex 00000006; asc
;; 1: len 6; hex 000001907504; asc
u ;; 2:
len 7; hex 0000000032081c; asc
2 ;;

Света.


это все может быть потому что какой то flush на диск переводит innodb в какой то sync режим?
если да то какой

Вячеслав, скиньте сюда в тред пожалуйста
SHOW VARIABLES LIKE '%innodb%'; ?

и еще судя по тому что большое кол-во NULL в SHOW PROCESS LIST
может все таки попробовать заменить mysql_pconnect на mysql_connect?

Sveta Smirnova

unread,
Oct 15, 2014, 8:18:38 AM10/15/14
to moscow-mysq...@googlegroups.com
Привет!


On 10/13/2014 07:03 PM, Viacheslav Romanov wrote:
Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.

Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.

Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)
Кстати, если приложения восстанавливается после "киляния", имеет смысл просто уменьшить innodb_lock_wait_timeout до минимального значения (1) или до скольких вашему приложению возможно ждать (значение по умолчанию 50 секунд). Тогда все транзакции, которые ждут локов слишком долго, будут автоматически убиваться.

Света.
--

Viacheslav Romanov

unread,
Oct 15, 2014, 1:26:53 PM10/15/14
to moscow-mysq...@googlegroups.com


On Wednesday, October 15, 2014 6:11:46 PM UTC+6, svetasmirnova wrote:
Привет!

On 10/13/2014 07:46 PM, Viacheslav Romanov wrote:
Ну и собственно что и ожидалось - упало прямо сейчас

SHOW ENGINE INNODB STATUS & SHOW PROCESSLIST в аттаче


В общем проблем блокировок строк я тут не вижу или вы очень быстро убиваете ожидающие процессы. В случае проблем блокировок, дедлоков и т.п. в списке TRANSACTIONS как правило есть транзакции, которые работают по несколько секунд (больше, чем среднее) и держат лок. У вас же наиболее долгоиграющие в статусе "starting index read" и есть несколько в "sending data" и "updating" (те могут ждать локов/держать локи на самом деле, но они бы были в этом статусе сильно больше, чем в среднем по процесслисту).

Спящие процессы в статусе "transaction not started" и, по идее, держать блокировок на уровне InnoDB не должны.

Пришлите вывод SHOW CREATE TABLE users и конфигурационный файл: посмотрим, почему так много транзакций в статусе "starting index read".

mysql> show create table users\G

*************************** 1. row ***************************

       Table: users

Create Table: CREATE TABLE `users` (

  `userId` bigint(20) unsigned NOT NULL,

  `episode` tinyint(4) NOT NULL,

  `level` tinyint(4) NOT NULL,

  `coins` int(11) NOT NULL,

  `receivedKeys` varchar(100) NOT NULL DEFAULT '',

  `refPlace` varchar(30) NOT NULL DEFAULT '',

  `lastLogin` date NOT NULL,

  `firstLogin` date NOT NULL,

  `paid` tinyint(4) NOT NULL DEFAULT '0',

  `lastPublication` int(10) unsigned NOT NULL,

  `lastGift` int(10) unsigned NOT NULL,

  `strip` tinyint(4) NOT NULL DEFAULT '0',

  `friendsHelpSended` tinyint(4) NOT NULL DEFAULT '0',

  `lastLevelPass` date NOT NULL,

  `lastPayDate` date NOT NULL,

  `getCoinsForInviteTime` int(10) unsigned NOT NULL,

  `powerUps` int(10) unsigned NOT NULL DEFAULT '0',

  `collectAction` tinyint(3) unsigned NOT NULL DEFAULT '0',

  `amountCollectCoinsFromFriends` int(10) unsigned NOT NULL DEFAULT '0',

  `shownForces` int(10) unsigned NOT NULL DEFAULT '0',

  `bonusLevelPlayTime` int(11) NOT NULL DEFAULT '0',

  `everydayBonusSeria` tinyint(4) NOT NULL DEFAULT '0',

  `everydayBonusCollected` tinyint(4) NOT NULL DEFAULT '0',

  `withoutLoseSeria` int(11) NOT NULL DEFAULT '0',

  `todayGachaPlayTimes` int(11) NOT NULL DEFAULT '0',

  `achievements` bigint(20) NOT NULL DEFAULT '0',

  PRIMARY KEY (`userId`)

) ENGINE=InnoDB DEFAULT CHARSET=latin1

1 row in set (0.00 sec)


key_buffer_size = 128M

max_allowed_packet = 16M

thread_stack = 192K

thread_cache_size       = 3000

# This replaces the startup script and checks MyISAM tables if needed

# the first time they are touched

myisam-recover         = BACKUP

max_connections        = 3000

table_open_cache       = 10000

thread_concurrency     = 24


max_heap_table_size    = 2G

max_connect_errors     = 1000000000

#

# * Query Cache Configuration

#

query_cache_limit = 0

query_cache_size        = 0

#

# * Logging and Replication

#

# Both location gets rotated by the cronjob.

# Be aware that this log type is a performance killer.

# As of 5.1 you can enable the log at runtime!

#general_log_file        = /var/log/mysql/mysql.log

#general_log             = 1


log_error                = /var/log/mysql/error.log

log_warnings = 2


# Here you can see queries with especially long duration

log_slow_queries = /var/log/mysql/mysql-slow.log

long_query_time = 0.2

#log-queries-not-using-indexes

#

# The following can be used as easy to replay backup logs or for replication.

# note: if you are setting up a replication slave, see README.Debian about

#       other settings you may need to change.

server-id=101

log_bin = /var/log/mysql/mysql-bin.log


expire_logs_days = 3

max_binlog_size     = 128M

#binlog_do_db = include_database_name

#binlog_ignore_db = include_database_name

#

# * InnoDB

#

# InnoDB is enabled by default with a 10MB datafile in /var/lib/mysql/.

# Read the manual for more InnoDB related options. There are many!

#


innodb_autoextend_increment = 1000

innodb_buffer_pool_size = 240G

innodb_additional_mem_pool_size = 128M

innodb_log_file_size = 512M

innodb_log_buffer_size = 32M

innodb_flush_log_at_trx_commit = 0

innodb_io_capacity = 3000


#concurrency ??

#file_per_table ???

#pool_instances ???


#???

#innodb_use_sys_malloc = 1


# danger!

innodb_support_xa = 0


#binlog_cache_size = 1M

#read_buffer_size = 1M

#sort_buffer_size = 2M


# * Security Features

#

# Read the manual, too, if you want chroot!

# chroot = /var/lib/mysql/

#

# For generating SSL certificates I recommend the OpenSSL GUI "tinyca".

#

# ssl-ca=/etc/mysql/cacert.pem

# ssl-cert=/etc/mysql/server-cert.pem

# ssl-key=/etc/mysql/server-key.pem




[mysqldump]

quick

quote-names

max_allowed_packet = 1G


[mysql]

#no-auto-rehash # faster start of mysql but no tab completition


[isamchk]

key_buffer_size = 512M

Viacheslav Romanov

unread,
Oct 15, 2014, 1:30:26 PM10/15/14
to moscow-mysq...@googlegroups.com
On Wednesday, October 15, 2014 6:18:38 PM UTC+6, svetasmirnova wrote:
Привет!

On 10/13/2014 07:03 PM, Viacheslav Romanov wrote:
Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.

Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.

Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)
Кстати, если приложения восстанавливается после "киляния", имеет смысл просто уменьшить innodb_lock_wait_timeout до минимального значения (1) или до скольких вашему приложению возможно ждать (значение по умолчанию 50 секунд). Тогда все транзакции, которые ждут локов слишком долго, будут автоматически убиваться.

Попробую - но это все-таки временное решение, даже если поможет. Вообще говороя, после киляние не всегда восстанавливается - там нужно стопнуть все, кильнуть потоки и подождать секунд 10 - тогда обычно работает.

Я подозреваю что проблема в checkpoint age - просто почему-то не флашит, а просто виснет. Ну это тоже теория - увеличил io_capacity, буду наблюдать
 

Света.

On Monday, October 13, 2014 3:01:20 PM UTC+6, Konstantin Osipov wrote:
* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 12:23]:
> Нет текста ошибки при дедлоке. А корка что такое?

А как вы узнаёте о них? только по innodb status?

--
http://tarantool.org - an efficient, extensible in-memory data store
--

---
Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user-group+unsub...@googlegroups.com.

Sveta Smirnova

unread,
Oct 16, 2014, 11:21:54 AM10/16/14
to moscow-mysq...@googlegroups.com
Привет!


On 10/15/2014 08:30 PM, Viacheslav Romanov wrote:
On Wednesday, October 15, 2014 6:18:38 PM UTC+6, svetasmirnova wrote:
Привет!

On 10/13/2014 07:03 PM, Viacheslav Romanov wrote:
Насколько я понял речь о core dump - в error.log было бы об этом упоминание, но там чисто.

Узнаю о них когда приложение "виснет" - не выполняются никакие запросы. В заббиксе падает запись на диск практически до нуля, в innodb status куча семафоров.

Отключаю приложение - киляю всех клиентов (php) - запускаю - работает (уже скрипт есть, удобно)
Кстати, если приложения восстанавливается после "киляния", имеет смысл просто уменьшить innodb_lock_wait_timeout до минимального значения (1) или до скольких вашему приложению возможно ждать (значение по умолчанию 50 секунд). Тогда все транзакции, которые ждут локов слишком долго, будут автоматически убиваться.

Попробую - но это все-таки временное решение, даже если поможет. Вообще говороя, после киляние не всегда восстанавливается - там нужно стопнуть все, кильнуть потоки и подождать секунд 10 - тогда обычно работает.
Кстати, обычно неплохое. Единственное, приложение должно быть написано таким образом, чтобы перезапустить транзакцию после того, как она была roll back.


Я подозреваю что проблема в checkpoint age - просто почему-то не флашит, а просто виснет. Ну это тоже теория - увеличил io_capacity, буду наблюдать

Обратите внимание на вот это замечание из мануала:

"For busy systems capable of higher I/O rates, you can set a higher value at server startup, to help the server handle the background maintenance work associated with a high rate of row changes. For systems with individual 5400 RPM or 7200 RPM drives, you might lower the value to the former default of 100." (http://dev.mysql.com/doc/refman/5.5/en/innodb-parameters.html#sysvar_innodb_io_capacity) Впрочем, судя по тому, что у вас innodb_buffer_pool_size 240G диски у вас тоже должны быть быстрые...

Ещё имеет смысл увеличить innodb_log_file_size до максимального значения (если у вас innodb_log_files_in_group по умолчанию 2, то для MySQL 5.5 это 2G).

Также во всех представленных выводах InnoDB Monitor есть вот такое:

-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
 insert 0, delete mark 0, delete 0
discarded operations:
 insert 0, delete mark 0, delete 0
Hash table size 509994437, node heap has 149087 buffer(s)
349.65 hash searches/s, 21282.72 non-hash searches/s

То есть adaptive hash index используется неэффективно на ваших запросах. Можно попробовать его отключить и потестировать.

Коммент по поводу SHOW CREATE TABLE: тут всё нормально, вы ищете по единственному индексу в таблице.

Света.
 

Света.

On Monday, October 13, 2014 3:01:20 PM UTC+6, Konstantin Osipov wrote:
* Viacheslav Romanov <rvv...@gmail.com> [14/10/13 12:23]:
> Нет текста ошибки при дедлоке. А корка что такое?

А как вы узнаёте о них? только по innodb status?

--
http://tarantool.org - an efficient, extensible in-memory data store
--

---
Вы получили это сообщение, поскольку подписаны на группу "Moscow MySQL User Group".
Чтобы отменить подписку на эту группу и больше не получать от нее сообщения, отправьте письмо на электронный адрес moscow-mysql-user-group+unsub...@googlegroups.com.

Чтобы настроить другие параметры, перейдите по ссылке https://groups.google.com/d/optout.

Viacheslav Romanov

unread,
Nov 10, 2014, 4:15:57 AM11/10/14
to moscow-mysq...@googlegroups.com
Спасибо за советы!

Насчет hash index - я его уже давно пробовал отключать, он действительно не полезен.

В целом проблема решилась - оказалось что все дело именно в checkpoint-е, он не успевал флашиться, и с увеличением io_capacity все заработало нормально.

С другой стороны это скорее баг в mysql, не должен он зависать из-за этого.

Еще раз спасибо!
Reply all
Reply to author
Forward
0 new messages