powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / MySQL [игнор отключен] [закрыт для гостей] / High Load mysql on Debian server - падает каждый день, почему?
25 сообщений из 89, страница 1 из 4
High Load mysql on Debian server - падает каждый день, почему?
    #38312671
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Есть Дебиан сервер 32гб оперативной памяти. На нем же стоит апач2 и нжинкс.

Нагрузка постоянно высокая. Иногда заканчивается память, хотя апач настроен только на 70 клиентов. Остальные сервисы (мемкешед например) не используют много памяти.
Когда нагрузка на пределе мускул останавливается. Я наблюдаю, что запросы спят и растет число подключений до максимума.
Мускул настроен использовать 24 гб памяти максимум.

В базе есть таблицы InnoDB с большим размером (больше 30гб, 400000 записей). Так же на сервере есть многопоточное приложение, которое осуществляет запись. Поэтому выбран InnoDB.

Вот мой конфиг


Код: 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.
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.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
123.
124.
125.
126.
127.
128.
129.
130.
131.
132.
133.
134.
135.
136.
137.
138.
139.
140.
141.
142.
143.
144.
145.
146.
147.
148.
149.
150.
151.
152.
153.
154.
155.
156.
157.
158.
159.
160.
161.
162.
163.
164.
165.
166.
167.
168.
169.
170.
171.
172.
173.
174.
175.
176.
177.
178.
179.
180.
181.
 [mysqld]
#
# * Basic Settings
#
default-time-zone = "+04:00"

user        = mysql
pid-file    = /var/run/mysqld/mysqld.pid
socket      = /var/run/mysqld/mysqld.sock
port        = 3306
basedir     = /usr
datadir     = /var/lib/mysql
tmpdir      = /tmp
language    = /usr/share/mysql/english

skip-external-locking

default-time-zone='Europe/Moscow'
#
# Instead of skip-networking the default is now to listen only on
# localhost which is more compatible and is not less secure.
#
# * Fine Tuning
#

#low_priority_updates   = 1
concurrent_insert   = ALWAYS

wait_timeout        = 600
interactive_timeout     = 600

#normal
key_buffer_size     = 2024M
#key_buffer_size        = 1512M

#70% hot cache
key_cache_division_limit= 70

#16-32
max_allowed_packet  = 32M
#1-16M
thread_stack        = 8M
#40-50
thread_cache_size   = 50

#orderby groupby sort
sort_buffer_size        = 64M
#same
myisam_sort_buffer_size = 400M

#temp table creates when group_by
tmp_table_size      = 3000M
#tables in memory
max_heap_table_size     = 3000M

#on disk
open_files_limit    = 10000
table_cache             = 10000

join_buffer_size = 5M

# This replaces the startup script and checks MyISAM tables if needed
# the first time they are touched

myisam-recover      = BACKUP
#myisam_use_mmap    = 1

max_connections         = 200

thread_concurrency      = 8

#
# * Query Cache Configuration
#

#more ignored
query_cache_limit       = 50M
query_cache_size        = 210M
#on query cache
query_cache_type = 1

#
# * Logging and Replication
#
# Both location gets rotated by the cronjob.
# Be aware that this log type is a performance killer.
#log        = /var/log/mysql/mysql.log
#
# Error logging goes to syslog. This is a Debian improvement :)
#
# Here you can see queries with especially long duration

log_slow_queries    = /var/log/mysql/mysql-slow.log
long_query_time = 1
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      = 1
#log_bin        = /var/log/mysql/mysql-bin.log

server-id   = 1
log-bin     = /var/lib/mysql/mysql-bin 
#replicate-do-db = gate
log-bin-index = /var/lib/mysql/mysql-bin.index
log-error = /var/lib/mysql/mysql-bin.err
relay-log = /var/lib/mysql/relay-bin
relay-log-info-file = /var/lib/mysql/relay-bin.info
relay-log-index = /var/lib/mysql/relay-bin.index
binlog_do_db            = 24avia

expire_logs_days    = 10
max_binlog_size         = 100M

read_buffer_size    = 4024288

innodb_buffer_pool_size     = 5000M
innodb_flush_log_at_trx_commit  = 2
innodb_thread_concurrency   = 8

table_definition_cache  = 2000

group_concat_max_len    = 16M

#binlog_do_db       = gate
#binlog_ignore_db   = include_database_name
#
# * BerkeleyDB
#
# Using BerkeleyDB is now discouraged as its support will cease in 5.1.12.
#skip-bdb
#
# * 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!
# You might want to disable InnoDB to shrink the mysqld process by circa 100MB.
#skip-innodb
#
# * 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  = 500M

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

[isamchk]
key_buffer      = 32M
key_buffer_size     = 512M

#
# * NDB Cluster
#
# See /usr/share/doc/mysql-server-*/README.Debian for more information.
#
# The following configuration is read by the NDB Data Nodes (ndbd processes)
# not from the NDB Management Nodes (ndb_mgmd processes).
#
# [MYSQL_CLUSTER]
# ndb-connectstring=127.0.0.1

#
# * IMPORTANT: Additional settings that can override those from this file!
#   The files must end with '.cnf', otherwise they'll be ignored.
#
!includedir /etc/mysql/conf.d/




Помогите сделать базу стабильной.

Использование памяти

Код: sql
1.
2.
3.
4.
5.
 /etc/mysql # free
          total       used       free     shared    buffers     cached
Mem:      32930800   32766424     164376          0     139208   23829196
-/+ buffers/cache:    8798020   24132780
Swap:     33553328      44660   33508668



Как видно моя проблема не в памяти, т.к. свободно 20 гб.

Каждый день утром база встает. Что это может быть?

Я пользуюсь mysqltuner и tunung-primer.sh.

Mysqltuner output

Код: 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.
46.
47.
48.
49.
50.
51.
52.
53.
54.
mysqltuner 

 >>  MySQLTuner 1.0.1 - Major Hayden <major@mhtx.net>;
 >>  Bug reports, feature requests, and downloads at http://mysqltuner.com/
 >>  Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.5.24-9-log
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive -BDB -Federated +InnoDB -ISAM -NDBCluster 
[--] Data in MyISAM tables: 112G (Tables: 1528)
[--] Data in InnoDB tables: 39G (Tables: 340)
[--] Data in PERFORMANCE_SCHEMA tables: 0B (Tables: 17)
[!!] Total fragmented tables: 344

-------- Performance Metrics -------------------------------------------------
[--] Up for: 8h 18m 33s (14M q [478.333 qps], 259K conn, TX: 9B, RX: 5B)
[--] Reads / Writes: 84% / 16%
[--] Total buffers: 10.5G global + 81.1M per thread (200 max threads)
[OK] Maximum possible memory usage: 26.3G (83% of installed RAM)
[OK] Slow queries: 1% (259K/14M)
[!!] Highest connection usage: 100%  (201/200)
[OK] Key buffer size / total MyISAM indexes: 1.5G/5.6G
[OK] Key buffer hit rate: 100.0% (6B cached / 1M reads)
[OK] Query cache efficiency: 74.3% (8M cached / 11M selects)
[OK] Query cache prunes per day: 0
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 247K sorts)
[!!] Joins performed without indexes: 106025
[!!] Temporary tables created on disk: 49% (351K on disk / 715K total)
[OK] Thread cache hit rate: 99% (249 created / 259K connections)
[!!] Table cache hit rate: 15% (2K open / 13K opened)
[OK] Open file limit used: 15% (3K/20K)
[OK] Table locks acquired immediately: 99% (4M immediate / 4M locks)
[!!] InnoDB data size / buffer pool: 39.4G/5.9G

-------- Recommendations -----------------------------------------------------
General recommendations:
    Run OPTIMIZE TABLE to defragment tables for better performance
    MySQL started within last 24 hours - recommendations may be inaccurate
    Reduce or eliminate persistent connections to reduce connection usage
    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
    Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
    max_connections (> 200)
    wait_timeout (< 600)
    interactive_timeout (< 600)
    join_buffer_size (> 5.0M, or always use indexes with joins)
    table_cache (> 10000)
    innodb_buffer_pool_size (>= 39G)



Mysql primer output

Код: 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.
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.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
118.
119.
120.
121.
122.
-- MYSQL PERFORMANCE TUNING PRIMER --
         - By: Matthew Montgomery -

MySQL Version 5.5.24-9-log x86_64

Uptime = 0 days 8 hrs 20 min 50 sec
Avg. qps = 478
Total Questions = 14369568
Threads Connected = 16

Warning: Server has not been running for at least 48hrs.
It may not be safe to use these recommendations

To find out more information on how each of these
runtime variables effects performance visit:
http://dev.mysql.com/doc/refman/5.5/en/server-system-variables.html
Visit http://www.mysql.com/products/enterprise/advisors.html
for info about MySQL's Enterprise Monitoring and Advisory Service

SLOW QUERIES
The slow query log is enabled.
Current long_query_time = 1.000000 sec.
You have 260626 out of 14369701 that take longer than 1.000000 sec. to complete
Your long_query_time seems to be fine

BINARY UPDATE LOG
The binary update log is enabled
Binlog sync is not enabled, you could loose binlog records during a server crash

WORKER THREADS
Current thread_cache_size = 50
Current threads_cached = 45
Current threads_per_sec = 0
Historic threads_per_sec = 0
Your thread_cache_size is fine

MAX CONNECTIONS
Current max_connections = 200
Current threads_connected = 11
Historic max_used_connections = 201
The number of used connections is 100% of the configured maximum.
You should raise max_connections

INNODB STATUS
Current InnoDB index space = 214 M
Current InnoDB data space = 39.40 G
Current InnoDB buffer pool free = 0 %
Current innodb_buffer_pool_size = 5.85 G
Depending on how much space your innodb indexes take up it may be safe
to increase this value to up to 2 / 3 of total system memory

MEMORY USAGE
Max Memory Ever Allocated : 23.46 G
Configured Max Per-thread Buffers : 15.84 G
Configured Max Global Buffers : 7.54 G
Configured Max Memory Limit : 23.39 G
Physical Memory : 31.40 G
Max memory limit seem to be within acceptable norms

KEY BUFFER
Current MyISAM index space = 5.61 G
Current key_buffer_size = 1.47 G
Key cache miss rate is 1 : 5578
Key buffer free ratio = 77 %
Your key_buffer_size seems to be fine

QUERY CACHE
Query cache is enabled
Current query_cache_size = 200 M
Current query_cache_used = 101 M
Current query_cache_limit = 50 M
Current Query cache Memory fill ratio = 50.59 %
Current query_cache_min_res_unit = 4 K
MySQL won't cache query results that are larger than query_cache_limit in size

SORT OPERATIONS
Current sort_buffer_size = 64 M
Current read_rnd_buffer_size = 256 K
Sort buffer seems to be fine

JOINS
Current join_buffer_size = 5.00 M
You have had 106606 queries where a join could not use an index properly
You have had 8 joins without keys that check for key usage after each row
join_buffer_size >= 4 M
This is not advised
You should enable "log-queries-not-using-indexes"
Then look for non indexed joins in the slow query log.

OPEN FILES LIMIT
Current open_files_limit = 20210 files
The open_files_limit should typically be set to at least 2x-3x
that of table_cache if you have heavy MyISAM usage.
Your open_files_limit value seems to be fine

TABLE CACHE
Current table_open_cache = 10000 tables
Current table_definition_cache = 2000 tables
You have a total of 1910 tables
You have 2151 open tables.
The table_cache value seems to be fine

TEMP TABLES
Current max_heap_table_size = 2.92 G
Current tmp_table_size = 2.92 G
Of 366426 temp tables, 49% were created on disk
Perhaps you should increase your tmp_table_size and/or max_heap_table_size
to reduce the number of disk-based temporary tables
Note! BLOB and TEXT columns are not allow in memory tables.
If you are using these columns raising these values might not impact your 
ratio of on disk temp tables.

TABLE SCANS
Current read_buffer_size = 3 M
Current table scan ratio = 2846 : 1
read_buffer_size seems to be fine

TABLE LOCKING
Current Lock Wait ratio = 1 : 185
You may benefit from selective use of InnoDB.
If you have long running SELECT's against MyISAM tables and perform
frequent updates consider setting 'low_priority_updates=1'

...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312679
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
автор[!!] Joins performed without indexes: 106025
[!!] Temporary tables created on disk: 49% (351K on disk / 715K total)
[!!] InnoDB data size / buffer pool: 39.4G/5.9G

авторМускул настроен использовать 24 гб памяти максимум.
чет ты не то насторил
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312689
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ScareCrowавтор[!!] Joins performed without indexes: 106025
[!!] Temporary tables created on disk: 49% (351K on disk / 715K total)
[!!] InnoDB data size / buffer pool: 39.4G/5.9G

авторМускул настроен использовать 24 гб памяти максимум.
чет ты не то насторил

Поменял в конфиге еще вот эти значения

Код: sql
1.
2.
3.
4.
5.
6.
innodb_buffer_pool_size         = 8000M
innodb_additional_mem_pool_size = 20M
innodb_log_file_size            = 512M
innodb_log_buffer_size          = 16M
innodb_flush_log_at_trx_commit  = 2
innodb_thread_concurrency       = 8



Мне нужно увеличить join_buffer_size ? Но тюнер не рекомендует делать его больше 5мб.
Temporary tables created on disk: 49% - у меня много записей с BLOB, для них эта настройка не актуальна.
InnoDB data size / buffer pool: 39.4G/5.9G - увеличен до 8 гб. Можно больше?
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312691
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поднять
innodb_buffer_pool_size = 5000M
slow query log показывай.
запросы у которых джойны не по индексам показывай.
авторmyisam_sort_buffer_size = 400M
о господи, зачем?
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312698
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторOf 366426 temp tables, 49% were created on disk
запросы кривые, да. показывай лучше их.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312701
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
ScareCrow,
innodb_buffer_pool_size установлен в 8гб. Сделать больше?

myisam_sort_buffer_size = 400M
Понятия не имею. :) Сколько поставить?

MyISAM использует другая база на том же сервере. Тоже не маленькая.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312713
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
myisam_sort_buffer_size = 256M

Сделал так, почитал на percona, действительно много.
slow-log сейчас скачаю на локалку, предварительно увидел там 2 запроса, которые повторяются чаще всего.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312746
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Код: sql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SELECT t.* FROM tickets_balance t,booking b WHERE 
                    (t.pnr_ru=b.pnr OR t.pnr_ru=b.pnr) AND ((b.pay_user=432 AND b.pay_user>999990) OR (b.pay_user_help='0' AND b.pay_user_help='999999') OR b.pay_account=432 )
                    AND t.deal_timestamp>='2013-03-01' AND t.deal_timestamp<='2100-01-01'
                    AND t.deal_timestamp>='2013-01-01 00:00:00' AND t.deal_type<>'REFUND'
                    AND (SELECT (id) FROM balance_opti WHERE status=1 AND level=1 AND ticket_id=t.id LIMIT 1) IS NULL
                    AND (SELECT id FROM tickets_balance t2 WHERE t2.bso=t.bso AND t2.deal_type='CANCEL' LIMIT 1) IS NULL
                    AND payed<>'acq' AND payed<>'krasplat' AND site<>2384 AND t.id NOT IN (290657,298381,300301,300298,300299,300297,300294)
                        AND t.bso NOT IN (SELECT bso FROM  `billing_take`)
                    
		    ORDER BY deal_timestamp;



Код: sql
1.
2.
SET timestamp=1372299914;
SELECT `c`.* FROM `pref_cache` AS `c`, `systems` AS `s` WHERE `c`.`id_system` = `s`.`id_system` AND `c`.`id_site` = '2384' AND `s`.`name` = 'sirena2000' AND ((`c`.`from` LIKE '%HRK%' AND `c`.`to` LIKE '%ANK%') OR (`c`.`to` LIKE '%HRK%' AND `c`.`from` LIKE '%ANK%')) LIMIT 1;



И еще пара запросов, которые просто оперируют большим объемом данных, например большой массив в serialize.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312748
Фотография ScareCrow
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
а планы этих запросов? а DDL таблиц?
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312752
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
По запросам пройдутся программисты. Подскажите больше по конфигурации.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312754
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторКаждый день утром база встает. Что это может быть?
Это нормальная физиологическая реакция на раздражение мочеполовых путей. попробуйте не пить на ночь много жидкости.

А если вы хотели узнать что происходит с ПО mysql, то опишите этот процесс нормально.
Что не работает, какие сообщения об ошибках видите и т.д.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312760
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyferПо запросам пройдутся программисты. Подскажите больше по конфигурации.
Раз вы не программист - ничего не трогайте. Дайте людям спокойно оценить ситуацию, подумать и поработать.
Перетасовка конфигов администраторами без понимания сути всегда приводит к какой-нибудь фигне.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312761
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
netwind,

если вы не будете придираться к конкретно этой фразе, и все такие прочитаете все остальное, то там все описано.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312763
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
netwind,

я как раз таки ведущий разработчик. у меня другие задачи в отделе сейчас.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312772
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyfer, я и прочитал все.

>Когда нагрузка на пределе мускул останавливается. Я наблюдаю, что запросы спят и растет число подключений до максимума.
Так не бывает. Вам просто кажется.
Обычно есть возможность подключиться от root и выполнить show processlist; потому что так задумано ( http://dev.mysql.com/doc/refman/5.1/en/too-many-connections.html)
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38312789
netwind
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyfer, понятно, что пока ситуация не повторится, понять чем именно занимается mysql нельзя.
Какой-нибудь мониторинг параметров mysql есть ? Логи mysql фиксируют т.н. dedlock-И ?
Придется поставить мониторинг, потому что гадать можно долго.

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

Попробуйте все-таки уменьшить tmp_table_size до адекватных и вынести tmp_dir в tmpfs. Хотя непосредственных причин делать это не вижу.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313509
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
netwind,

tmp_table_size - адекватное, это сколько?

Я мониторю через workbeanch с убунты, выполняет тот же show process list , только в GUI.
И я наблюдаю именно то, что наблюдаю. При это число запросов растет, т.к. демон их посылающий продолжает работать, до исчерпания лимита подключений. Сам процесс mysql не останавливается, он продолжает "висеть", только ни одного запроса не выполняется, query все в состоянии sleep и с течением времени сам по себе сервер не разгружается.
Только перезагрузка mysql спасает.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313511
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyfer,

0. Оптимизация таблиц БД. Проще всего сделать полный дамп, остановить Мускуль и перезалить всё из дампа "на чистую". Не представляю как вручную найти 344 таблицы, требующих оптимизации. Возможно есть смысл отказаться от постоянных соединений с Мускулем...

1. Поставьте критическое время и смотрите лог медленных запросов. Это первое. Там по-хорошему не должно быть НИЧЕГО при заданном пороге. Совсем ничего. Каждый запрос, анализируйте на предмет ширины выборки (а надо ли всё), количества записей и главное - наличие индексов. Как только, ваши программисты оптимизируют всё, двигаемся дальше.

В этом же пункте должно уйти "джойны без индексов"...

2. Смотрите на создание временных таблиц на диске. Этого тоже не должно быть совсем, если по-хорошему. Перестраивайте логику запросов и ХП так, чтобы всё работало в оперативе. Тем более у вас её "хоть ...опой". Как только ваши программисты решат этот вопрос, двигайтесь дальше.

3. Смотрите статус иннодебила на предмет блокировок, ломанных индексов и т.д.

4. Только после выполнения п0-3 начинайте играться с параметрами Мускуля по оптимизации.

ИМХО: классический Г-код, с вполне ожидаемыми последствиями. Программистов, во главе с главным - бить по рукам рублем.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313514
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arhat109seyfer,

0. Оптимизация таблиц БД. Проще всего сделать полный дамп, остановить Мускуль и перезалить всё из дампа "на чистую". Не представляю как вручную найти 344 таблицы, требующих оптимизации. Возможно есть смысл отказаться от постоянных соединений с Мускулем...

1. Поставьте критическое время и смотрите лог медленных запросов. Это первое. Там по-хорошему не должно быть НИЧЕГО при заданном пороге. Совсем ничего. Каждый запрос, анализируйте на предмет ширины выборки (а надо ли всё), количества записей и главное - наличие индексов. Как только, ваши программисты оптимизируют всё, двигаемся дальше.

В этом же пункте должно уйти "джойны без индексов"...

2. Смотрите на создание временных таблиц на диске. Этого тоже не должно быть совсем, если по-хорошему. Перестраивайте логику запросов и ХП так, чтобы всё работало в оперативе. Тем более у вас её "хоть ...опой". Как только ваши программисты решат этот вопрос, двигайтесь дальше.

3. Смотрите статус иннодебила на предмет блокировок, ломанных индексов и т.д.

4. Только после выполнения п0-3 начинайте играться с параметрами Мускуля по оптимизации.

ИМХО: классический Г-код, с вполне ожидаемыми последствиями. Программистов, во главе с главным - бить по рукам рублем.

Конструктивно.

0. Прогнал сегодня ночью mysqloptimize утилиту по всем базам. Делалась долго, но почему-то после перезапуска базы тюнер снова говорит, что дефрагментировано 300 баз. Я тут в замешательстве, я же только что прогнал оптимизацию.

1. По логам уже с подачи товарища выше прошлись, запросы оптимизированы. Все же проблема скорее всего на уровне системы или железа.

2. Тут, к сожалению, нет такого опыта. Чтобы не создавались временные таблицы рекомендуется увеличивать параметр temp_table_cache и open_file_limit. При увеличении все равно 50%, т.к. у нас используются BLOB поля, такие таблицы не записываются в память. Как иначе?

3. Мониторинг workbeanch выполняется. Таких проблем не обнаружено.

4. Вот мы и пришли к этому пункту и я написал на форум.

Бить никого не надо. Надо помогать. :)
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313515
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
seyfer,

tmp_table_size конечно же.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313523
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyfer,

"как всё запущено"... :)

1. "Чукча не читатель". Перечитайте п.1. по буковкам... сделать дамп и загрузить его заново. Это долго... может быть очень долго... но это позволит гарантировать файловую оптимизацию таблиц. По сути "снести всё и поставить базы заново, записав их последовательно на диск"...

2. "Чукча не читатель2". За одно только SELECT t.* и BLOB поля - всех прогеров можно в 80% случаев увольнять без выходного пособия, а первым - ведущего разработчика. Должно быть строгое(!) обоснование применимости широкой выборки и тем более хранении blob полей... оно есть, точно? Расскажете зачем?

3. следствие п.2. Временные таблицы... они ваще зачем в явном виде?!? ЭТО ОБОСНОВАНО? А ежели в неявном, то тем более надо гнать метлой. Смотрите запросы... там точно надо джойнить всю таблицу, без этого никак?

4. Ну хоть тут ровно...

Ещё раз: ваше приложение требует глубокой оптимизации запросов к Мускулю. Тюнинг настроек надо делать ПОСЛЕ неё.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313526
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyfer,

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

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

Путем подкрутки сервера вы добавите еше двух человек в бригаду
и замените резиновую плетку погоншика на настояшую кожаную.
ВЫ добьетесь произовдительности 14 мепков в минуту, на 40% больше.
Но привезут 15 шеков и все встанет.
Нельзя с таким запасом работать.

*****************

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

Если вы хотите чтоб база хоть как-то дышала, то УМЕНЬШИТЕ
количество соединений и УМЕНЬШИТЕ тимеоуты.
Поставьте не 200 а 40 --- если не будет падать база, то 80.
По крайней мере часть запросов с ПО будет проходить нормально.

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

То что вы привели в качестве примера из слоу-квери-лога --
очень неуклюжий код с повторами -- очевидно сгенерированый
так-себейным кверигенератором. Вам придется найти
опытного специалиста разгрести ... при чем НЕ этот конкретный код
а как минимум на парочку уровней выше.
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313527
Arhat109
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
seyfer,

Для понимания, приведите эксплейн первого выданного вами запроса или его теперешней модификации, заодно и КАК изменили...
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313528
seyfer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Arhat109,

BLOB для очень больших объемов данных. Есть цельные данные, такие как xml и массивы, они сжимаются COMPRESS, так и хранятся в BLOB. Предложите решение лучше для больших данных. (только не надо предлагать no-sql базы).
...
Рейтинг: 0 / 0
High Load mysql on Debian server - падает каждый день, почему?
    #38313529
Фотография javajdbc
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
... ну вот, пока я лирику писал, Arhat109
всю правду-матку и зарезал :-)
...
Рейтинг: 0 / 0
25 сообщений из 89, страница 1 из 4
Форумы / MySQL [игнор отключен] [закрыт для гостей] / High Load mysql on Debian server - падает каждый день, почему?
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]