Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
Здравствуйте, подскажите в чем может быть проблема (логи вложил) - не могу найти узкое место в настройках MySQL - периодически происходят падения - выдержка из логов (логов больше но после данного сообщения идут крушения таблиц): 170818 09:26:51 mysqld_safe Number of processes running now: 0 170818 09:26:51 mysqld_safe mysqld restarted 170818 9:26:52 [Note] /usr/libexec/mysqld (mysqld 5.5.52-MariaDB) starting as process 18295 ... 170818 9:26:54 InnoDB: The InnoDB memory heap is disabled 170818 9:26:54 InnoDB: Mutexes and rw_locks use GCC atomic builtins 170818 9:26:54 InnoDB: Compressed tables use zlib 1.2.7 170818 9:26:54 InnoDB: Using Linux native AIO 170818 9:26:54 InnoDB: Initializing buffer pool, size = 1.0G 170818 9:26:54 InnoDB: Completed initialization of buffer pool 170818 9:26:54 InnoDB: highest supported file format is Barracuda. InnoDB: Log scan progressed past the checkpoint lsn 615475503196 170818 9:26:54 InnoDB: Database was not shut down normally! InnoDB: Starting crash recovery. InnoDB: Reading tablespace information from the .ibd files... InnoDB: Restoring possible half-written data pages from the doublewrite InnoDB: buffer... InnoDB: Doing recovery: scanned up to log sequence number 615480745984 InnoDB: Doing recovery: scanned up to log sequence number 615485988864 InnoDB: Doing recovery: scanned up to log sequence number 615491231744 InnoDB: Doing recovery: scanned up to log sequence number 615496474624 InnoDB: Doing recovery: scanned up to log sequence number 615501717504 InnoDB: Doing recovery: scanned up to log sequence number 615506960384 InnoDB: Doing recovery: scanned up to log sequence number 615512203264 InnoDB: Doing recovery: scanned up to log sequence number 615517446144 InnoDB: Doing recovery: scanned up to log sequence number 615522689024 InnoDB: Doing recovery: scanned up to log sequence number 615526177569 170818 9:27:10 InnoDB: Starting an apply batch of log records to the database... InnoDB: Progress in percents: 0 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 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 InnoDB: Apply batch completed 170818 9:28:50 InnoDB: Waiting for the background threads to start 170818 9:28:51 Percona XtraDB ( http://www.percona.com) 5.5.49-MariaDB-38.0 started; log sequence number 615526177569 170818 9:28:51 [Note] Plugin 'FEEDBACK' is disabled. 170818 9:28:53 [Note] Event Scheduler: Loaded 0 events 170818 9:28:53 [Note] /usr/libexec/mysqld: ready for connections. Version: '5.5.52-MariaDB' socket: '/var/lib/mysql/mysql.sock' port: 0 MariaDB Server 170818 9:28:54 [ERROR] mysqld: Table './newregiontehsnab/wa_contact' is marked as crashed and should be repaired 170818 9:28:54 [Warning] Checking table: './newregiontehsnab/wa_contact' 170818 9:29:01 [ERROR] mysqld: Table './newregiontehsnab/shop_category' is marked as crashed and should be repaired 170818 9:29:01 [Warning] Checking table: './newregiontehsnab/shop_category' 170818 9:29:01 [ERROR] mysqld: Table './newregiontehsnab/shop_product' is marked as crashed and should be repaired 170818 9:29:01 [Warning] Checking table: './newregiontehsnab/shop_product' 170818 9:29:03 [ERROR] mysqld: Table './newregiontehsnab/shop_category_products' is marked as crashed and should be repaired 170818 9:29:03 [ERROR] mysqld: Table './newregiontehsnab/shop_category_products' is marked as crashed and should be repaired ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2017, 09:58 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
Ну разрушена БД. Бывает. Лечите. https://dev.mysql.com/doc/refman/5.7/en/innodb-troubleshooting.html ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.08.2017, 10:06 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
понятно что разрушена, пытаюсь найти причину разрушения пока вот что нашел: срабатывала служба ядра OOM Killer, предназначенная для освобождения оперативной памяти путем принудительного завершения работы процессов. # cat /var/log/messages | grep "oom-kill" Aug 21 09:31:50 regiontehsnab kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Aug 21 09:31:50 regiontehsnab kernel: nginx invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Aug 21 09:45:13 regiontehsnab kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2017, 18:53 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
dermuterпонятно что разрушена, пытаюсь найти причину разрушения пока вот что нашел: срабатывала служба ядра OOM Killer, предназначенная для освобождения оперативной памяти путем принудительного завершения работы процессов. # cat /var/log/messages | grep "oom-kill" Aug 21 09:31:50 regiontehsnab kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Aug 21 09:31:50 regiontehsnab kernel: nginx invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 Aug 21 09:45:13 regiontehsnab kernel: mysqld invoked oom-killer: gfp_mask=0x201da, order=0, oom_score_adj=0 ...оом-киллер... поишите гугле "mysql oom-killer", вроде даже на этом форуме было обсуждение. Вариантов точной проблемы и решений -- несколько, самая распостраненая -- оптимистичная резервация памяти линуксом в сумме большем чем физической памяти. В результате если все начнут занимать свою зарезервированую память то она (памят-) физически кончится и система вызывает oom-killer. Лечить запрешением оптимистичного резервирования где-то в настройках кернеля линукса.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2017, 21:48 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.08.2017, 21:52 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
javajdbcЛечить запрешением оптимистичного резервирования где-то в настройках кернеля линукса.... Ну здрасте. mysql потребляет памяти в прямой зависимости от числа клиентов и настроек буферов. так что настраивать надо их ( и клиентов тоже) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 13:34 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
Настройки ядра позволяют только лишь не трогать mysqld во время процесса экстренной зачистки памяти с помощью oom-killer. Это да. но все равно это не очень красиво. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 13:35 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
netwindjavajdbcЛечить запрешением оптимистичного резервирования где-то в настройках кернеля линукса.... Ну здрасте. mysql потребляет памяти в прямой зависимости от числа клиентов и настроек буферов. так что настраивать надо их ( и клиентов тоже) И вам здрасте. внутренние дела mysql не имеют прямого отношения к проблеме и к решению. Даже если настроить лимиты mysql в 10 раз меньше, оом-кил все равно может произойти... Проблема в том как линукс (1) резервирует разным процессам память заранее и (2) потом раздает память кодга разные процессы начинают реально просить память. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:06 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
netwindНастройки ядра позволяют только лишь не трогать mysqld во время процесса экстренной зачистки памяти с помощью oom-killer. Это да. но все равно это не очень красиво. вы прочитали половину проблемы и половину решения. Вот обе половинки: 1. можно настроить САМ оом-килл чтоб он не трогал mysql до самого последнего момента... но все равно убьет если приспичит... 2. можно указать ядру линукса в ЯВНОМ виде не создават- условия для оом-килла -- а имено -- запретить оптимистичное резервирование памяти В предыдушем обсуждении ( 17610458 ) если статейка по теме. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:12 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
javajdbc2. можно указать ядру линукса в ЯВНОМ виде не создават- условия для оом-килла -- а имено -- запретить оптимистичное резервирование памяти В предыдушем обсуждении ( 17610458 ) если статейка по теме. Имхо, никто так не делает в хостинге где mysql не выделен специально. И в данном случае даже nginx упомянут. Программы в принципе склонны выделять памяти больше чем используют. Какая-то странная настройка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:19 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
netwindjavajdbc2. можно указать ядру линукса в ЯВНОМ виде не создават- условия для оом-килла -- а имено -- запретить оптимистичное резервирование памяти В предыдушем обсуждении ( 17610458 ) если статейка по теме. Имхо, никто так не делает в хостинге где mysql не выделен специально. И в данном случае даже nginx упомянут. Программы в принципе склонны выделять памяти больше чем используют. Какая-то странная настройка. Это настройки сервера -- если нет к ним доступа то и разговор, конечно же, ни о чем. У меня был доступ к серверу и я проблему решил имено так не "зажимая" мускл. Если у ТС нет доступа к серверу то пусть ищет выделенку или путается "зажать" мускл (без гарантий на решение) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:29 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
javajdbc, и тем не менее, все равно оба совета плохих. Это не будет эффективно. Решать лучше подбором числа клиентов : если php-fpm - там указать, если apache - maxclients. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 14:40 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
netwindjavajdbc, и тем не менее, все равно оба совета плохих. Это не будет эффективно. Решать лучше подбором числа клиентов : если php-fpm - там указать, если apache - maxclients. ...не торопитесь ругать то что вы не поняли... ...вы предлагаете "зажать" апликации, вместо того чтоб решать первопричину. Ваше решение НЕ гарантирует результата (отсутсвие остановок по оом-кил)... ...а так - да, настраивать сервер аппликации и сервер базы надо ппо любому, но это не решение данной проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 15:55 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
javajdbc, да тут нет никаких аппликацый. Тут просто сайты. Тут все всегда со всеми ясно. Настолько ясно, что firstvds к примеру, эти параметры изначально выставляет в шаблоне vds. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 15:58 |
|
||
|
буду признателен за помощь в анализе логов - падает база
|
|||
|---|---|---|---|
|
#18+
netwindjavajdbc, да тут нет никаких аппликацый. Тут просто сайты. Тут все всегда со всеми ясно. Настолько ясно, что firstvds к примеру, эти параметры изначально выставляет в шаблоне vds. ок, замнём для ясности.... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.08.2017, 16:07 |
|
||
|
|

start [/forum/topic.php?fid=47&fpage=68&tid=1830452]: |
0ms |
get settings: |
8ms |
get forum list: |
11ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
26ms |
get topic data: |
13ms |
get forum data: |
2ms |
get page messages: |
65ms |
get tp. blocked users: |
1ms |
| others: | 231ms |
| total: | 363ms |

| 0 / 0 |
