私は数週間にわたって、サーバーの 1 つでパフォーマンスの問題に悩まされてきました。
構成: Ubuntu 16.04、Mysql 5.7.21 (すべて MyISAM)、Apache 2.4.18 (mpm prefork)、Php 7.0.25 を搭載した専用サーバー。128GB の RAM
CPU の使用パターンは本当に奇妙で、それを説明するものは何も見つかりませんでした。 https://i.stack.imgur.com/88VMm.jpg
ご覧のとおり、CPU 使用率には連続したレベルがあり、かなり一定しています。また、Apache の CPU 使用率が増加すると、Mysql の CPU 使用率も増加し、一方が減少すると、もう一方も減少します。また、ご覧のとおり、全体的な違いは CPU システム使用率で発生します。
私は MySQL のクエリ数/秒を調べましたが、これは基本的に一定です。Apache2 のクエリ数/秒についても同じです。かなり一定です。ちなみに、Apache サーバーは約 100 クエリ/秒で、MySQL は ~300 クエリ/秒です (したがって、CPU のスパイクは、Apache または MySQL での通常の大量のリクエストとは関係がないようです)
遅いクエリを調べましたが、特に何もありませんでした。SHOW PROCESSLIST を実行すると、クエリは残っていません。Apache でも同じです。最大ページ読み込み時間は 1 秒未満です。
apache2 サービスを再起動すると、パターンは数時間消えるようです。mysql サービスを再起動すると、パターンも数時間消えるようです。
また、このデータベースを使用する他の Java サービスもいくつかあります (最新の jdbc ドライバーを使用しており、CPU パターンの変更は見られません)。当初はサービスの開始時に MySQL への接続を作成していましたが、この動作を変更して、5 分ごとに接続を閉じて新しい接続を開始するようにしました... これにより何も変わりませんでした。
私の my.cnf ファイル:
[mysqld_safe]
socket = /var/run/mysqld/mysqld.sock
nice = 0
[mysqld]
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
lc-messages-dir = /usr/share/mysql
skip-external-locking
bind-address = 0.0.0.0
key_buffer_size = 36G
max_allowed_packet = 64M
tmp_table_size = 256M
max_heap_table_size = 256M
max_connections = 512
table_open_cache = 8192
bulk_insert_buffer_size = 512M
thread_stack = 192K
thread_cache_size = 8
sort_buffer_size = 64M
myisam_sort_buffer_size = 64M
myisam-recover-options = BACKUP
query_cache_limit = 1M
query_cache_size = 16M
log_error = /var/log/mysql/error.log
expire_logs_days = 10
max_binlog_size = 100M
[isamchk]
key_buffer_size = 36G
sort_buffer_size = 8M
read_buffer = 4M
write_buffer = 4M
私の Apache はほぼデフォルトの設定になっていますが、(約 350 のワーカーを使用できるため、この値を設定しています)
MaxRequestWorkers 1024
ServerLimit 1024
次に何を調査すればいいのか本当にわかりません。
何が間違っているのか、何か考えはありますか?
ありがとう !
編集: ApacheやMySQLのログには何も疑わしいものは見つかりませんでした
編集:コメントで尋ねられたいくつかのデータ
ulimit -a:
core file size (blocks, -c) 0
data seg size (kbytes, -d) unlimited
scheduling priority (-e) 0
file size (blocks, -f) unlimited
pending signals (-i) 514833
max locked memory (kbytes, -l) 64
max memory size (kbytes, -m) unlimited
open files (-n) 50000
pipe size (512 bytes, -p) 8
POSIX message queues (bytes, -q) 819200
real-time priority (-r) 0
stack size (kbytes, -s) 8192
cpu time (seconds, -t) unlimited
max user processes (-u) 514833
virtual memory (kbytes, -v) unlimited
file locks (-x) unlimited
iostat -x
Linux 4.4.0-112-generic (ns340707.ip-37-187-250.eu) 02/21/2018 _x86_64_ (12 CPU)
avg-cpu: %user %nice %system %iowait %steal %idle
14.89 0.29 10.42 1.41 0.00 72.98
Device: rrqm/s wrqm/s r/s w/s rkB/s wkB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sdb 0.70 51.90 18.37 11.86 1179.98 1894.25 203.33 1.40 46.40 10.29 102.33 2.35 7.11
sda 0.73 51.89 25.27 11.87 1847.55 1894.25 201.50 1.22 32.72 4.37 93.05 2.14 7.93
md0 0.00 0.00 9.63 62.19 758.90 1889.96 73.77 0.00 0.00 0.00 0.00 0.00 0.00
nvme1n1 0.00 0.00 429.64 1214.09 4755.77 6215.04 13.35 0.36 0.19 0.18 0.19 0.03 5.00
md2 0.00 0.00 1567.33 1204.69 14913.87 6204.69 15.24 0.00 0.00 0.00 0.00 0.00 0.00
nvme0n1 0.00 0.00 1204.85 1215.25 10676.20 6219.68 13.96 1.57 0.62 0.14 1.10 0.05 11.93
グローバルステータスを表示 ->https://pastebin.com/AehMqQQq
グローバル変数を表示 ->https://pastebin.com/JyGquqFx
Mysql チューナーの出力:https://pastebin.com/F8wvbHec
「高システムCPU」フェーズ中に、isolate_freepages_blockのCPU使用率が高いことに気付きました。(私は を使ってそれを取得しましたperf top
)。しかし、私はこれをどう解決するかわかりません
答え1
これらはすべて、SET GLOBAL xxx=xxx で設定できる動的変数です。要求された順序に従ってください。1 日に 1 回だけ実行し、シャットダウンして再起動すると、何日もかかりますが、その後は非常に順調に動作します。
時間の許す限り調査して追求してください。このチューニング サイクル中に、奇妙な使用パターンはなくなる可能性があります。
my.cnf/ini [mysqld] セクションの提案
max_connections=325 #from 512 to support 270 max_used_connections
#max_allowed_packet=64M # lead for 1M default WHEN YOU NEED more
セッションの開始時に、必要な場合にのみ、SET @max_allowed_packet=67108864 # を設定して、RAMのフットプリントを削減します。MySQLTunerは次のように報告しました
query_cache_size=0 # from 16M, not being used, conserve RAM
query_cache_limit=1K # from 1M, conserve RAM
query_cache_min_res_unit=512 #from 4096, for > results stored, if ever used
thread_cache_size=100 # from 8 to reduce ~ 240,000 threads_created a day
次の3つ(1日に3つすべてを実行する)は、MyISAMのkey_buffer管理を強化します。
key_cache_division_limit=50 # from 100 default for Hot/Warm separation
key_cache_block_size=64K # from 1K let's clear more RAM when full
key_cache_age_threshold=64800 # from 300 KEEP 18 HRS vs 5M to reduce RD RPS
innodb_lru_scan_depth=128 # from 1024 to conserve CPU cycles
innodb_stats_sample_pages=32 # from 8 to improve statistics cardinality
max_seeks_for_key=32 # from a huge # to limit OPTIMIZER depth
max_write_lock_count=16 # from a huge # to allow RD after NN write locks
table_open_cache=16000 # from 8192 to support ~ 350,000 opened_tables daily
SSD をお持ちの場合は、チャンスはもっとあります。 1 日ほど前にコメントで質問しました。
答え2
- MyISAM から InnoDB に切り替えます。(および を変更します
key_buffer_size
。innodb_buffer_pool_size
) - 低く
MaxRequestWorkers 1024
、そしてmax_connections = 512
- 店が混雑して誰も動けなくなるよりは、新しい人が食料品店に入らないようにする方が良いです。270 Max_used_connections
「雷鳴のような群れ」を意味する場合もあります。 - クエリキャッシュはおそらく助けるよりも害を及ぼす。忙しい生産システムでは、書く、QC を頻繁にフラッシュする必要があります。したがって、他のテストとは関係なく、
query_cache_type=0
およびに変更しますquery_cache_size=0
。 - Java のガベージ コレクションを確認します。
喜んでレビューしますSHOW GLOBAL STATUS;
ので、SHOW VARIABLES
再投稿してください(期限が切れています)。