web-dev-qa-db-ja.com

利用可能な大量のRAMと交換する

スワップに奇妙な問題がある古いレガシーサーバーがあります。

  • Linuxバージョン：Red Hat Enterprise Linux Serverリリース5.6（Tikanga）
  • カーネルバージョン：2.6.18-238.el5
  • サーバーはvirtualです。
  • サーバーには2つの仮想ソケットがあります。

スワップパーティションが小さすぎてスワップファイルが追加されることはわかっていますが、再起動から数時間後、状況は次のようになります。

free -m
             total       used       free     shared    buffers     cached
Mem:         15922      15806        116          0        313      13345
-/+ buffers/cache:       2147      13775
Swap:         2047       2042          4

Oracleデータベースはインストールされていますが、ほとんど使用されていません。なぜメモリ分散がこのようになるのか理解したいと思います。つまり、13345がキャッシュされ、無料を意味します。なぜスワップを埋めるのですか？

以前のsysadminは、swappinessを3に構成していました。
巨大なページは構成されていません。

私はいくつかの同様の投稿を見ましたが、理解するための解決策がありませんでした。ここでの答え： linux redhat 5.4-メモリがまだ利用可能なときにスワップ はnumaについて話しているので、少し掘り下げました（私はdbadminであり、sysadminではないので、何かを見逃した場合は申し訳ありません）。

grep NUMA=y /boot/config-`uname -r`
CONFIG_NUMA=y
CONFIG_K8_NUMA=y
CONFIG_X86_64_ACPI_NUMA=y
CONFIG_ACPI_NUMA=y

dmesg | grep -i numa
NUMA: Using 63 for the hash shift.

だから、質問は：なぜこのマシンが交換されているのか理解できますか？

Update次の場合：vmstat 2

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0 2090852 122224 324056 13679328  320    0   498  1898 1088 3555 32 10 56  2  0
 1  0 2090724 139740 324068 13680984   64    0    76   932 1028 3534  7  2 90  2  0
 0  0 2090724 132416 324068 13681436    0    0    16   240 1016 3401  3  1 96  1  0
 4  0 2090660 116916 324084 13683404    0    0    72  1396 1070 3617 11  9 80  1  0
 0  0 2090420 126544 324084 13687008  128    0   188  1872 1068 3436 35  8 56  2  0

アップデート3

ipcs -ma

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x61a4d538 5210113    Oracle    660        4096       0
0xba8cafdc 5242883    Oracle    660        4096       0
0x16621634 5308420    Oracle    660        4096       0
0xc15f3dac 5373957    Oracle    660        4096       0

------ Semaphore Arrays --------
key        semid      owner      perms      nsems
0x24690d60 98304      Oracle    660        125
0x24690d61 131073     Oracle    660        125
0x24690d62 163842     Oracle    660        125
0x24690d63 196611     Oracle    660        125
0x24690d64 229380     Oracle    660        125
0x24690d65 262149     Oracle    660        125
0x24690d66 294918     Oracle    660        125
0x24690d67 327687     Oracle    660        125
0x24690d68 360456     Oracle    660        125
0x6285541c 491529     Oracle    660        125
0x6285541d 524298     Oracle    660        125
0x6285541e 557067     Oracle    660        125
0x6285541f 589836     Oracle    660        125
0x62855420 622605     Oracle    660        125
0x62855421 655374     Oracle    660        125
0x62855422 688143     Oracle    660        125
0x62855423 720912     Oracle    660        125
0x62855424 753681     Oracle    660        125
0xaee7ccbc 884754     Oracle    660        125
0xaee7ccbd 917523     Oracle    660        125
0xaee7ccbe 950292     Oracle    660        125
0xaee7ccbf 983061     Oracle    660        125
0xaee7ccc0 1015830    Oracle    660        125
0xaee7ccc1 1048599    Oracle    660        125
0xaee7ccc2 1081368    Oracle    660        125
0xaee7ccc3 1114137    Oracle    660        125
0xaee7ccc4 1146906    Oracle    660        125
0xfb4a455c 1277979    Oracle    660        125
0xfb4a455d 1310748    Oracle    660        125
0xfb4a455e 1343517    Oracle    660        125
0xfb4a455f 1376286    Oracle    660        125
0xfb4a4560 1409055    Oracle    660        125
0xfb4a4561 1441824    Oracle    660        125
0xfb4a4562 1474593    Oracle    660        125
0xfb4a4563 1507362    Oracle    660        125
0xfb4a4564 1540131    Oracle    660        125

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages
linuxredhatmemory-usageswap
5
user_0

アクティブなページング（vmstatではsi/so）があまり発生していない場合は、心配する必要はありません。カーネルは、スワップに積極的に使用されていないプログラムコードのビットを配置することを選択しているため、より多くのDBファイルをRAM（無料でキャッシュ）に保持できます。

これは私がスワップについて見つけた優れた芸術であり、それを使用することは必ずしも悪いことではありません。 https://chrisdown.name/2018/01/02/in-defence-of-swap.html

2
Slashterix

良くない。非常に偶発的なsi以外のものがある場合は、基本的に「適切なスワップ」の領域外です。そして、あなたのシステムは常にそれを行っています。 SwapInは、一部のプログラムが待機していることを意味し、ユーザーが速度低下を経験する可能性があることを意味します（ローカルまたはリモートユーザー）。

私はすべてその良いスワップについてです。つまり、ほとんどの場合soは、肥大化したものを貴重なRAMから押し出します。それは肥大化しているので、非常に非常に偶発的なスワップイン活動をしている人は誰も使用していないディスク上にあります。

あなたは私が以前に見たOracleでおかしなことに遭遇しました：どういうわけかOracleはそのSGAを「キャッシュ」として報告します（私が正しく覚えていれば、それは匿名mmapです）。しかし、匿名であるため、システムがいつでも簡単にドロップできるのはメモリではないため、freeではありません！全く逆-それは頻繁に使用されます。 Oracleは、データファイルを読み取るときに、実際の残りのシステムキャッシュも使用することがよくあります。これにより、キャッシュに多くのメモリ負荷がかかる可能性があります（デフォルトの動作はダム）。

したがって、freeが、すべての「キャッシュ」が「無料」として扱われるべきだと誤解させる多くのケースの1つです。この経験則は、ほとんどが読み取り専用のファイルサーバーのみを対象としています。 （それが、freeの作成者が「キャッシュ」が「使用されている」上という行を意味する行に置いている理由だと思います「キャッシュ」は「無料」です。）

また、システムが100％占有スワップを持っている限り、swappinessをまったく調整しないでください。それは...賢明ではありません。

あなたのSGAは2 GBではないに違いないが、10 GB以上かもしれない。 SGAを6 GBに構成すると、スワップインが減少し、スワップにプッシュされるものがはるかに少なくなると思います。段階的に増加させると、圧力がどのように上昇するかがわかります。

2
kubanczyk