☰

Webサーバーのメモリリーク

tag-icon • tag-icon memory
Webサーバーのメモリリーク

だから最近、サーバーのパフォーマンスの問題が発生しました。現在、4GBと160GBのディスク容量を持つFedoraサーバーを実行しています。ディスク上のすべてのファイルをほぼすべて使用しました。私たちはそれぞれ、複数のバックアップを含む複数のウェブサイトを運営しています。しかし、実際にトラフィックが発生したウェブサイトは1つだけでした。訪問者が多いeコマースサイトです。

最近のロード時間が遅くなり、利用可能なメモリが非常に低くなりました（1 GB未満）。サーバーを再起動すると（1日3回再起動する必要があります）、すべてがうまくいくでしょう。最初は2.2GBのメモリを確保しましたが、3〜4時間後にはメモリが枯渇し、ロード時間がゆっくり増加することが確認できます。これがどこから来るのか、より良いサーバーにアップグレードする必要があるのか​​わかりません。私はアップグレードしたくないので、MySQLリクエストのどこかにボトルネックが発生していることに気づきます。

どんなアイデアや提案でも大変感謝いたします。

編集する-

3つの仮想ホストを使用すると、60,000を超えるファイルがあります。

             total       used       free     shared    buffers     cached
Mem:          4003       3372        630          0        398       1717
-/+ buffers/cache:       1256       2746
Swap:         8189          0       8189

21:21:49 up 46 min,  1 user,  load average: 3.75, 4.20, 4.03

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  2      0 592728 409640 1838360    0    0   165   411  953  473  9  8 47 36  0

トップスショット。

 1356 mysql     20   0 1374m 219m 5320 S  5.6  5.5  14:06.21 mysqld
15796 root      20   0  103m  20m  440 D  1.0  0.5   0:04.42 sendmail
 1081 root      20   0  103m  20m  440 D  0.7  0.5   0:21.73 sendmail
24013 root      20   0 97416  22m 2648 D  0.7  0.6   0:15.15 mailq
 1525 root      20   0  247m 7980 3472 S  0.3  0.2   0:06.88 vlogger (access
 1530 apache    20   0  539m  13m 3008 S  0.3  0.3   0:03.56 httpd
 2399 apache    20   0  539m  12m 2748 S  0.3  0.3   0:00.85 httpd
 5763 root      20   0  121m 4932 3868 S  0.3  0.1   0:00.07 sshd
12326 apache    20   0  539m  12m 2992 S  0.3  0.3   0:00.38 httpd
12421 apache    20   0  539m  12m 2988 S  0.3  0.3   0:00.45 httpd
16396 apache    20   0  538m  12m 2284 S  0.3  0.3   0:00.09 httpd
17050 root      20   0 15368 1256  868 R  0.3  0.0   0:00.09 top
    1 root      20   0 37336 4104 1908 S  0.0  0.1   0:02.82 systemd
    2 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kthreadd
    3 root      20   0     0    0    0 S  0.0  0.0   0:00.03 ksoftirqd/0
    5 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/0:0H
    6 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kworker/u:0
    7 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/u:0H
    8 root      RT   0     0    0    0 S  0.0  0.0   0:00.11 migration/0
    9 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/0
   10 root      RT   0     0    0    0 S  0.0  0.0   0:00.14 migration/1
   12 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/1:0H
   13 root      20   0     0    0    0 S  0.0  0.0   0:00.02 ksoftirqd/1
   14 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/1
   15 root      RT   0     0    0    0 S  0.0  0.0   0:00.15 migration/2
   17 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/2:0H
   18 root      20   0     0    0    0 S  0.0  0.0   0:00.03 ksoftirqd/2
   19 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/2
   20 root      RT   0     0    0    0 S  0.0  0.0   0:00.11 migration/3
   22 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 kworker/3:0H
   23 root      20   0     0    0    0 S  0.0  0.0   0:00.02 ksoftirqd/3
   24 root      RT   0     0    0    0 S  0.0  0.0   0:00.01 watchdog/3
   25 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 cpuset
   26 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 khelper
   27 root      20   0     0    0    0 S  0.0  0.0   0:00.00 kdevtmpfs
   28 root       0 -20     0    0    0 S  0.0  0.0   0:00.00 netns
   29 root      20   0     0    0    0 S  0.0  0.0   0:00.00 xenwatch

ベストアンサー1

1分ごとにsarを起動し、psテーブルを出力します。私の詳細な答えを見るここ。

次にサーバーがクラッシュしたときの追跡sar -rに使用されます。いつそんなことが起こる。ここで、ps-cronjobまたは私の出力を使用してください。githubのps用Perlラッパー、どのプロセスが原因であるかを調べてください。

サーバーが12:00:00から13:00:00の間に爆発したとします。使用sar -r -s 12:00:00 -e 13:00:00。これにより、データが急増していることがわかります。 （より簡単な場合は、プロットを実行するJavaベースのユーティリティがありますが、一般的に問題を引き起こす価値はありません。）次に、ps列の出力で時間範囲（例：12:00〜12:15）を検索し、pid、時間順に並べ替え、メモリ列を見てみましょう。

awk '/^=== .* 12:00:/,/^=== .* 12:16:/' /var/log/sa/ps/today |
 sort -k 1n -k 16

（ソートオプションでは、時間が16列にあると仮定していますが、そうでない場合もありません。）これで、awkを介してこの出力を再フィルタリングして、出力ライン間の違いを見つけることができます。

... | awk 'lastpid && lastpid==$1 && last != $0 { print} /^[0-9]/ { lastpid=$1;last=$0; }'

かなり粗雑なフィルターです。 mysql、postgresql、snmpdなど、コマンドラインが変更され続ける一部のプロセスでは、これはあまり役に立ちませんが、awkを調整して犯人を見つけるのに役立ちます。

おすすめ記事