質問をすることでしか得られない、回答やアドバイスがある。

15分調べてもわからないことは、質問しよう!

新規登録して質問してみよう
ただいま回答率
85.50%
CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

Linux

Linuxは、Unixをベースにして開発されたオペレーティングシステムです。日本では「リナックス」と呼ばれています。 主にWebサーバやDNSサーバ、イントラネットなどのサーバ用OSとして利用されています。 上位500のスーパーコンピュータの90%以上はLinuxを使用しています。 携帯端末用のプラットフォームAndroidは、Linuxカーネル上に構築されています。

Q&A

解決済

6回答

48516閲覧

メモリのスワップ領域の空き容量が0になってしまいます。

moriyama

総合スコア259

CentOS

CentOSは、主にRed Hat Enterprise Linux(RHEL)をベースにした、フリーのソフトウェアオペレーティングシステムです。

Linux

Linuxは、Unixをベースにして開発されたオペレーティングシステムです。日本では「リナックス」と呼ばれています。 主にWebサーバやDNSサーバ、イントラネットなどのサーバ用OSとして利用されています。 上位500のスーパーコンピュータの90%以上はLinuxを使用しています。 携帯端末用のプラットフォームAndroidは、Linuxカーネル上に構築されています。

1グッド

8クリップ

投稿2015/07/08 05:47

編集2015/07/08 06:15

お世話になります。

現在、稼働中のWebサーバにて、物理メモリの空き容量があるにもかかわらず、スワップ領域を100%使ってしまい、スワップ領域の空きがないという現象が発生しております。
改善を図るにはどうしたらよいでしょうか。
OSはCentOS6.4です。

以下に、関連すると思われるコマンドの出力を羅列します。

$ free total used free shared buffers cached Mem: 16443276 5096000 11347276 0 332164 3360440 -/+ buffers/cache: 1403396 15039880 Swap: 4095992 4095992 0

Swapのfreeが0になっています。

$ uname -a Linux localhost.localdomain 2.6.32-358.2.1.el6.x86_64 #1 SMP Wed Mar 13 00:26:49 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
$ cat /etc/redhat-release CentOS release 6.4 (Final)
$ cat /proc/meminfo MemTotal: 16443276 kB MemFree: 11393580 kB Buffers: 332164 kB Cached: 3369660 kB SwapCached: 90288 kB Active: 3399304 kB Inactive: 1158360 kB Active(anon): 2401504 kB Inactive(anon): 580472 kB Active(file): 997800 kB Inactive(file): 577888 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 4095992 kB SwapFree: 0 kB Dirty: 24 kB Writeback: 0 kB AnonPages: 765552 kB Mapped: 25476 kB Shmem: 2126136 kB Slab: 349232 kB SReclaimable: 305408 kB SUnreclaim: 43824 kB KernelStack: 1624 kB PageTables: 19376 kB NFS_Unstable: 0 kB Bounce: 0 kB WritebackTmp: 0 kB CommitLimit: 12317628 kB Committed_AS: 7510372 kB VmallocTotal: 34359738367 kB VmallocUsed: 304364 kB VmallocChunk: 34359429240 kB HardwareCorrupted: 0 kB AnonHugePages: 507904 kB HugePages_Total: 0 HugePages_Free: 0 HugePages_Rsvd: 0 HugePages_Surp: 0 Hugepagesize: 2048 kB DirectMap4k: 4096 kB DirectMap2M: 2084864 kB DirectMap1G: 14680064 kB
$ cat /proc/sys/vm/swappiness 60

swappinessは出来る限り変更せずに解決したいです。

top - 14:34:54 up 790 days, 13:59, 3 users, load average: 0.06, 0.06, 0.07 Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 1.6%us, 0.4%sy, 0.0%ni, 97.4%id, 0.6%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16443276k total, 5113416k used, 11329860k free, 332164k buffers Swap: 4095992k total, 4095992k used, 0k free, 3370900k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ SWAP COMMAND 1799 root 20 0 98.1m 1884 1092 S 0.0 0.0 13:52.34 18m miniserv.pl 19704 root 20 0 6057m 66m 9936 S 0.0 0.4 75:38.55 3692 java 1963 root 20 0 97.9m 1244 788 S 0.0 0.0 188:02.48 3000 snmpd 1620 root 20 0 15080 584 580 S 0.0 0.0 0:00.00 2228 config 1531 root 20 0 247m 9.8m 760 S 1.0 0.1 7655:18 916 lsi_mrdsnmpagen 1708 root 20 0 78728 2016 1916 S 0.0 0.0 3:03.50 760 master 1717 postfix 20 0 78980 2024 1868 S 0.0 0.0 0:43.42 748 qmgr 6006 root 20 0 64116 624 520 S 0.0 0.0 6:04.32 568 sshd 1726 root 20 0 20408 760 672 S 0.0 0.0 4:23.37 552 crond 1608 root 20 0 52104 192 188 S 0.0 0.0 0:00.00 500 vsftpd 555 root 16 -4 10676 312 308 S 0.0 0.0 0:00.07 456 udevd 1603 root 20 0 52104 292 236 S 0.0 0.0 0:00.19 452 vsftpd 10811 root 18 -2 10672 260 256 S 0.0 0.0 0:00.00 452 udevd 10812 root 18 -2 10672 200 196 S 0.0 0.0 0:00.00 452 udevd 1462 haldaemo 20 0 25504 1848 1088 S 0.0 0.0 5:24.76 352 hald 15046 ntp 20 0 30160 1204 1072 S 0.0 0.0 0:38.62 320 ntpd 1380 root 20 0 244m 5520 872 S 0.0 0.0 8:16.67 296 rsyslogd 1618 root 20 0 13104 648 644 S 0.0 0.0 0:00.00 272 log 1615 root 20 0 19256 348 344 S 0.0 0.0 0:00.00 224 dovecot 1463 root 20 0 18104 764 760 S 0.0 0.0 0:00.01 196 hald-runner 1491 root 20 0 20248 808 804 S 0.0 0.0 0:00.01 168 hald-addon-inpu 1617 dovecot 20 0 12972 600 596 S 0.0 0.0 0:00.00 164 anvil 1737 root 20 0 21452 312 292 S 0.0 0.0 0:00.42 160 atd 1438 dbus 20 0 21400 808 624 S 0.0 0.0 0:03.54 116 dbus-daemon 1430 root 20 0 10884 532 412 S 0.0 0.0 103:31.64 100 irqbalance 1 root 20 0 19352 1292 1076 S 0.0 0.0 1:27.79 92 init 1505 haldaemo 20 0 17804 936 852 S 0.0 0.0 0:00.66 72 hald-addon-acpi 1810 root 20 0 4060 460 456 S 0.0 0.0 0:00.00 64 mingetty 1812 root 20 0 4060 460 456 S 0.0 0.0 0:00.00 64 mingetty 1814 root 20 0 4060 460 456 S 0.0 0.0 0:00.00 64 mingetty 1816 root 20 0 4060 460 456 S 0.0 0.0 0:00.00 64 mingetty 1818 root 20 0 4060 460 456 S 0.0 0.0 0:00.00 64 mingetty 25336 root 20 0 4060 456 452 S 0.0 0.0 0:00.00 64 mingetty 1453 root 20 0 4076 560 504 S 0.0 0.0 0:00.16 52 acpid

topコマンドをSwap順にソートしています。

top - 14:43:00 up 790 days, 14:07, 3 users, load average: 0.02, 0.08, 0.08 Tasks: 169 total, 2 running, 167 sleeping, 0 stopped, 0 zombie Cpu(s): 2.3%us, 0.3%sy, 0.0%ni, 97.2%id, 0.3%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 16443276k total, 5119408k used, 11323868k free, 332164k buffers Swap: 4095992k total, 4095992k used, 0k free, 3374408k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 19704 root 20 0 6057m 66m 9936 S 0.0 0.4 75:38.82 java 31465 apache 20 0 337m 52m 5520 S 0.7 0.3 0:01.03 httpd 31224 apache 20 0 336m 52m 6184 S 0.0 0.3 0:20.18 httpd 31317 apache 20 0 335m 51m 5924 S 0.3 0.3 0:09.55 httpd 31327 apache 20 0 332m 48m 5928 S 0.7 0.3 0:12.33 httpd 31375 apache 20 0 332m 48m 5888 S 0.3 0.3 0:07.18 httpd 31158 apache 20 0 332m 48m 5892 S 0.3 0.3 0:15.36 httpd 31326 apache 20 0 330m 46m 6008 S 0.3 0.3 0:12.13 httpd 31380 apache 20 0 330m 46m 5976 S 0.3 0.3 0:06.99 httpd 31377 apache 20 0 329m 45m 5888 S 0.7 0.3 0:06.20 httpd 31467 apache 20 0 329m 45m 5852 S 0.3 0.3 0:02.61 httpd 31250 apache 20 0 328m 44m 5920 S 0.3 0.3 0:16.33 httpd 31459 apache 20 0 328m 44m 5884 S 0.3 0.3 0:03.48 httpd 31460 apache 20 0 328m 44m 5888 S 0.3 0.3 0:02.59 httpd 31331 apache 20 0 328m 44m 5924 S 0.7 0.3 0:13.09 httpd 31461 apache 20 0 325m 40m 5896 S 0.7 0.3 0:01.14 httpd 31283 apache 20 0 324m 40m 6092 S 0.3 0.3 0:10.86 httpd 31318 apache 20 0 324m 40m 5924 S 0.3 0.3 0:14.48 httpd 31379 apache 20 0 324m 40m 5976 S 0.3 0.3 0:08.05 httpd 30750 apache 20 0 324m 40m 6112 S 0.7 0.3 0:44.45 httpd 31466 apache 20 0 324m 40m 5888 S 0.7 0.3 0:01.78 httpd 16068 root 20 0 296m 16m 8760 S 0.0 0.1 5:46.89 httpd 1531 root 20 0 247m 9.8m 760 S 0.3 0.1 7655:22 lsi_mrdsnmpagen 1380 root 20 0 244m 5520 872 S 0.0 0.0 8:16.67 rsyslogd 27015 root 20 0 143m 52m 3096 S 0.3 0.3 0:06.41 spamd 27016 root 20 0 143m 50m 684 S 0.0 0.3 0:00.03 spamd 27018 root 20 0 143m 50m 684 S 0.0 0.3 0:00.02 spamd 31024 user001 20 0 105m 1804 1448 S 0.0 0.0 0:00.01 bash 31162 user001 20 0 105m 1796 1448 S 0.0 0.0 0:00.01 bash 31385 user001 20 0 105m 1796 1448 S 0.0 0.0 0:00.02 bash 1799 root 20 0 98.1m 1884 1092 S 0.0 0.0 13:52.34 miniserv.pl 1963 root 20 0 97.9m 1244 788 S 0.0 0.0 188:02.58 snmpd

VIRT順にソートすると、こうなります。

以上、よろしくお願いします。

kuwako👍を押しています

気になる質問をクリップする

クリップした質問は、後からいつでもMYページで確認できます。

またクリップした質問に回答があった際、通知やメールを受け取ることができます。

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

guest

回答6

0

ベストアンサー

df するとどのような結果になるでしょうか?
tmpfs に巨大なファイルがあったりしないでしょうか?


/dev/shm になにか巨大なファイルがありませんか?
そこは tmpfs というメモリベースのファイルシステムみたいなものです。
それが原因でスワップを圧迫しているように思います。

投稿2015/07/08 12:29

編集2015/07/09 01:22
ngyuki

総合スコア4514

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moriyama

2015/07/09 01:18

回答ありがとうございます。 dfは以下のような結果になります。 $ df Filesystem 1K-ブロック 使用 使用可 使用% マウント位置 /dev/sda3 956426956 99536216 808307012 11% / tmpfs 8221636 6185552 2036084 76% /dev/shm /dev/sda1 247919 72690 162429 31% /boot
ngyuki

2015/07/09 01:22

追記しました
moriyama

2015/07/09 03:07

/dev/shmに6GB程度のファイルが存在しました。 これを/homeなりに移動すれば解消されるのでしょうか?
ngyuki

2015/07/09 03:10

解消されるかどうかはやってみなければわかりませんが可能性は高いです。 また、そのファイルが何のために存在するのかわからないため、移動や削除することで新たな問題が発生しないかどうかもわかりません。
moriyama

2015/07/09 03:38

配置されていたのが.gzファイルだったので、圧縮時の一時フォルダとして利用されていた可能性が高いのかなと思います。 他のシステムなどで読み込んでいなければ移動して大丈夫とみていい感じですかね。 そもそも、単純なWebサーバとしての利用以外の用途はないので、httpdの障害を誘発する可能性が低いと判断できれば、削除してみようかと思います。 ありがとうございます!
ngyuki

2015/07/09 07:49

この件、ファイルを削除してみた結果、スワップの問題は解決されたでしょうか?
moriyama

2015/07/14 09:37

ご連絡遅れましてすみません。 消すのにいろいろと手続きが必要で、遅れました。 削除してみた結果ですが、問題解決されました! ありがとうございました!
guest

0

まず、この状況ではなにも障害は出ていないと思います。Swap space の値は無視してください。
スラッシングが起きてはじめて問題になります。

Swap space が使われることは問題ありません。メモリの中で長い間使われていない領域が
Swap out されているだけです。
他のサーバーとの違いは、他のサーバーの動作しているプログラムはメモリを全体的に
平均的に使うのに対して、このサーバーはよく使う部分と、使わない部分がはっきり分かれているからです。
Java や Perl はコードがかなり多く、使われない部分も多く、負荷が低いということは使われない部分はほぼ使われないので、このようなことは起きうるでしょう。

もし、Swap space が使われるということが数値的に出ることが嫌ならば vm.swappiness を 0にするしかありません。

16GB に対して、4GB のSwap で、いびつでも何でもないです。問題ありません。

投稿2015/07/08 11:43

katsumiy

総合スコア479

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

eripong

2015/07/08 12:37 編集

仰るとおりですね。 Webアクセス障害が起きているということで、 その原因は別途調査が必要そうですが、スワップが原因にはなりませんね。
moriyama

2015/07/09 01:24

回答ありがとうございます。 なるほど、アクセス障害の原因は他にありそうということですね。 また、16GBに対して、4GBのSwapはいびつでないということもわかりました。 ただ、ApacheとMySQL以外の部分に関しては、共通なはずなので、JavaやPerlのコードが原因というのは少し疑問です。 現状、VPSを使用していて、コンテンツはHTML+PHPのみなので、JavaやPerlのコードはVPSにデフォルトでインストールされている管理ソフトか何かに使用されているものと思います。 他の同じVPSのサーバもJavaやPerlのコードが含まれているのにもかかわらず、発生しません。
guest

0

RHEL 6 / CentOS 6 でしょうか?
6.4 の kernel-2.6.32-358.el6 にバグがあり、より多く swapout してしまうようです。
ディスクI/Oで高負荷になるなどの問題がなければ、そのままでいいのではないでしょうか。

https://access.redhat.com/solutions/33375

There is also a bug in version kernel-2.6.32-358.el6 (6.4), whereby the amount of swap
utilized increases dramatically over previous versions even though free still shows
substantial memory is still available. This is a private bugzilla at this time.

This issue is tracked via Red Hat Private Bug 949166 - Much increased swap usage, io
performance regression with -358 kernel. This bug is not publicly accessible. For more
information about this bug, please contact Red Hat Global Support Services.

This bug is not fixed in RHEL 6.5 and is still being worked.

投稿2015/07/08 07:16

TaichiYanagiya

総合スコア12141

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moriyama

2015/07/08 07:53 編集

回答ありがとうございます。 他にも同一のOSを搭載したサーバを管理していますが、このような現象は起きていません。 動作するソフトウェアなどによる何かしらの条件があるのでしょうか…。
TaichiYanagiya

2015/07/08 07:53

例えば、httpd へのアクセス数が多く、子プロセスを起動するためより多くのメモリを必要として、他のアイドルプロセスのメモリを swapout しているとか。
moriyama

2015/07/08 08:09

アクセス数でいえば、確かに瞬発的に高負荷がかかることがあるサーバではあります。 バグとの兼ね合いで負荷がかかるたびにswapoutしてしまうといったかたちなのでしょうか…… ちなみに、他の同一の正常なサーバは、Webアプリを動作させていて、アクセス数は少ないですが、MySQLを動作させていたり、定期処理で重い動作をさせたりしているので、メモリ使用量の観点では、正常なサーバの方がメモリを使用しています。
TaichiYanagiya

2015/07/08 08:42

正常なサーバの方がメモリを使用しているとのことですので、ちょっと原因がわかりません。 根拠に乏しい仮定ですが、 (1) 瞬発的にアクセスが増え httpd 子プロセスの実メモリ使用量が多くなる (2) swapout が起きる (3) httpd 子プロセスが MaxRequestsPerChild 設定値までリクエストを処理後、再起動し、現在の実メモリ使用量は少なくなっている とか。 瞬発的にアクセスが増えたときの httpd の実メモリ使用量と Swap使用量の遷移を調べないとわかりませんが、もしそうだとすると、httpd.conf の MaxRequestsPerChild を小さくして、子プロセスの実メモリ使用量が多くなる前に再起動させてしまえば、緩和することができるかもしれません。
moriyama

2015/07/08 10:49

ただ、もし現状のスワップ領域に空きがない状態で、瞬発的アクセスが再度あったとき、swapoutできずにメモリ使用量の多いプロセスがカーネルによってkillされないかが心配です。 とりあえず実メモリ容量が大きく、今のところ多数のアクセスにも耐えられてはいることから、実際の物理メモリ容量を超えてswapoutしたとは考えにくいですし、子プロセスの再起動でメモリを離さないのであれば、何かしらのメモリリークが原因の可能性もありますかね……
guest

0

ここここにあるようなコマンドで、スワップ領域を使用しているプロセスを絞り込めないでしょうか?

cat /proc/$$/smaps | grep -i swap | awk 'BEGIN{sum=0}{sum+=$2}END{print sum}'
grep VmSwap /proc/*/status | sort -k 2 -r | head

投稿2015/07/08 06:14

eripong

総合スコア1546

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moriyama

2015/07/08 06:24 編集

grep VmSwap /proc/*/status | sort -k 2 -r | head を実行してみましたが、topコマンドのSwap降順ソート時と同様の結果になりました。 $ grep VmSwap /proc/*/status | sort -k 2 -r | head /proc/1799/status:VmSwap: 19020 kB /proc/19704/status:VmSwap: 3692 kB /proc/1963/status:VmSwap: 3000 kB /proc/1620/status:VmSwap: 2228 kB /proc/1531/status:VmSwap: 916 kB /proc/1708/status:VmSwap: 760 kB /proc/1717/status:VmSwap: 748 kB /proc/6006/status:VmSwap: 568 kB /proc/1726/status:VmSwap: 552 kB /proc/1608/status:VmSwap: 500 kB
eripong

2015/07/08 07:03

なるほど。 NUMAアーキテクチャの影響でしょうか? CPUのノード数はどうなっているでしょうか? http://d.hatena.ne.jp/fat47/20121121/1353495937 にあるように、 # numactl --hardware で確認してみてはいかがでしょうか? また、スワップが0になることで、サーバ動作上の問題は、 発生しているでしょうか?
moriyama

2015/07/08 07:54 編集

回答ありがとうございます。 ノード数により不均一にメモリが割り当てられることがあるのですね。 勉強になりました。 ですが、今回のサーバはノード数が1なので、そのようなことはなさそうです。 $ numactl --hardware available: 1 nodes (0) node 0 cpus: 0 1 2 3 node 0 size: 16359 MB node 0 free: 10869 MB node distances: node 0 0: 10 サーバ動作上の問題についてですが、実は同一構成のサーバがもう1台あります。 そのサーバはこのようなスワップ領域を使い切る現象が起きていない状況です。 また、今回のこの問題のサーバは、何度かApacheの再起動で復旧するようなWebアクセス障害が発生しています。 正常なもう1台のサーバでは、このようなアクセス障害が起きていません。 正常なサーバの方ではMySQLも動作しています。 問題のサーバはMySQLを稼働させていません。 なぜ、問題のサーバだけが不安定なのか調査したところ、スワップ容量の空きがないのが原因では?との予測になり、とりあえず解消させて様子を見たいといったところです。
eripong

2015/07/08 11:14 編集

NUMAは関係なさそうですね。 Webアクセス障害が発生しているとなると、 放置できませんね。 # swapoff -a # swapon -a してみたら、どうでしょうか?
eripong

2015/07/08 11:20 編集

そういえば、スワップの空き容量の推移は、どの様になっているでしょうか? 徐々に増えるイメージですか?高負荷のタイミングと合いますか? sarなど残っていませんか?
eripong

2015/07/08 13:57 編集

katsumiyさんの回答を踏まえて、 アクセス障害の原因を現在のスワップ容量が0であることから調査するのは、 (直接の原因の可能性が低いため)時間がかかりそうに思います。 アクセス障害が起きた時点、その前後の情報を元に調査を行う方が 早いように思います。 その方向の調査は実施されているでしょうか? 少し話題が違うので、別質問にした方が良いかも知れません。
moriyama

2015/07/09 01:43

なるほどです。ありがとうございます。 実をいうと、私の方で完全に契約・管理・監視しているサーバではなくて、アクセス障害発生当時の情報がほとんど残っていなくて、とりあえずメモリを怪しんでいるという状況です。(sarや各種ログも時間がたちすぎて消失してます) アクセス障害への対策に関してはとりあえず、障害が再発したときに、原因を追えるような環境を整えておくような方向で進めようかと思います。
guest

0

apache の prefork で実行しているのでしょうか。

top コマンドを見ただけで、
java が 6G 程度、apache 1プロセスが 300M を超えていて、
約 20プロセス程度が稼働していますね。
java + apache で約 12GB 使用している計算になります。
(バッファが少ない感じ)

サーバの物理メモリ16GB、スワップ4GB なので、
apache プロセスが 26, 7 追加されると
スワップアウトになりそうです。

取り急ぎ、
httpd.conf で apache の子プロセスの上限を
正常サーバと問題サーバで比較されてはいかがでしょうか。

投稿2015/07/08 11:31

編集2015/07/08 11:33
NSakai

総合スコア14

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moriyama

2015/07/09 01:28

回答ありがとうございます。 httpd.confの値は、正常サーバ、問題サーバ共に共通です。 <IfModule prefork.c> StartServers 8 MinSpareServers 5 MaxSpareServers 20 ServerLimit 256 MaxClients 256 MaxRequestsPerChild 4000 </IfModule>
guest

0

スワップ領域を拡大できませんか?

ディスク上にスワップ領域を確保するのは、物理メモリの容量よりも大きなメモリ空間を使った処理を可能にするためです。
そのスワップ領域を使い切ってしまっているのですから、今の計算機の使われ方に対してスワップ領域が不足しているという事です。

解決作は2つあります。
1) 不要なプロセスを停止して、使用するメモリの量を減らす。
2) スワップ領域を拡大する。

私は、スワップ領域を拡大する方をお勧めします。

物理メモリの容量とスワップ領域の大きさの比率は、1:1.5~4程度にするのが普通です。
ところが、質問を見ると

total

Mem: 16443276
Swap: 4095992

スワップ領域(4GB)が物理メモリ(16GB)の4分の1しかないというのは、相当いびつです。
スワップ領域を32GBに変更すれば、問題は解決すると思います。

投稿2015/07/08 07:22

coco_bauer

総合スコア6915

バッドをするには、ログインかつ

こちらの条件を満たす必要があります。

moriyama

2015/07/08 07:54 編集

回答ありがとうございます。 他の管理しているサーバではこのようなスワップ領域を使い切る現象が起きていないので、単にこのままスワップ領域を拡大しても、また同様に、本来物理メモリに配置されるはずのデータがスワップ領域に不自然に流れてしまうのではないかといった懸念があります。 スワップ領域を広くすれば、使い切ることはなくなるかもしれませんが、やはり物理メモリに余裕があるのに大量にスワップ領域を消費するという現象には疑問が残ります。
guest

あなたの回答

tips

太字

斜体

打ち消し線

見出し

引用テキストの挿入

コードの挿入

リンクの挿入

リストの挿入

番号リストの挿入

表の挿入

水平線の挿入

プレビュー

15分調べてもわからないことは
teratailで質問しよう!

ただいまの回答率
85.50%

質問をまとめることで
思考を整理して素早く解決

テンプレート機能で
簡単に質問をまとめる

質問する

関連した質問