☰

長い話を短く

tag-icon • tag-icon rhel kernel memory docker out-of-memory
長い話を短く

AWS EC2内のCentos7に基づいて構築されたJenkinsインスタンスでDockerコンテナを構築または実行しています。 2つのCPUと3.5GBの空きメモリを備えた2つのt2.mediumインスタンスがあります。
場合によっては、別のコンテナ内にコンテナを作成し、単にドラッグして実行します（他のコンテナ）。

エラーが発生し始めました。

open /var/lib/docker/overlay/<sha>-init/merged/dev/console: cannot allocate memory

私達はjournalctl得た

page allocation failure: order:4

ページキャッシュダンプを実行すると、問題が一時的に解決される可能性があります。

echo 1 > /proc/sys/vm/drop_caches

だから私はドッカータスクを実行するとDirtyメモリブロックが（必要に応じて）急増し、Mappedその後にジャンプすることがわかりました。しかし、DirectMap4k今回のジャンプは比較的近いです。

たとえば、
アイドルマシン

cat /proc/meminfo | grep -P "(Dirty|Mapped|DirectMap4k)"
Dirty:               104 kB
Mapped:            45696 kB
DirectMap4k:      100352 kB

主な動機

cat /proc/meminfo | grep -P "(Dirty|Mapped|DirectMap4k)"
Dirty:             72428 kB
Mapped:            70192 kB
DirectMap4k:      100352 kB

したがって、このマシンが失敗し始めるのにはしばらく時間がかかりますが、同じマシンは報告され、定期的にDirectMap4k: 77824 kB失敗しますが（よ​​り複雑なコンテナの構築も処理しなければなりません）sysctl vm。

Dockerコンテナをビルド/実行するとメモリ不足エラーが発生し、問題はカーネルを安定させるためにどの調整が必要かです。

ドッカーバージョン

Client:
 Version:      17.06.0-ce
 API version:  1.30
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:20:36 2017
 OS/Arch:      linux/amd64

Server:
 Version:      17.06.0-ce
 API version:  1.30 (minimum version 1.12)
 Go version:   go1.8.3
 Git commit:   02c1d87
 Built:        Fri Jun 23 21:21:56 2017
 OS/Arch:      linux/amd64
 Experimental: false

コア3.10.0-327.10.1.el7.x86_64

システム制御仮想マシン

vm.admin_reserve_kbytes = 8192
vm.block_dump = 0
vm.dirty_background_bytes = 0
vm.dirty_background_ratio = 10
vm.dirty_bytes = 0
vm.dirty_expire_centisecs = 3000
vm.dirty_ratio = 30
vm.dirty_writeback_centisecs = 500
vm.drop_caches = 1
vm.extfrag_threshold = 500
vm.hugepages_treat_as_movable = 0
vm.hugetlb_shm_group = 0
vm.laptop_mode = 0
vm.legacy_va_layout = 0
vm.lowmem_reserve_ratio = 256   256     32
vm.max_map_count = 65530
vm.memory_failure_early_kill = 0
vm.memory_failure_recovery = 1
vm.min_free_kbytes = 67584
vm.min_slab_ratio = 5
vm.min_unmapped_ratio = 1
vm.mmap_min_addr = 4096
vm.nr_hugepages = 0
vm.nr_hugepages_mempolicy = 0
vm.nr_overcommit_hugepages = 0
vm.nr_pdflush_threads = 0
vm.numa_zonelist_order = default
vm.oom_dump_tasks = 1
vm.oom_kill_allocating_task = 0
vm.overcommit_kbytes = 0
vm.overcommit_memory = 0
vm.overcommit_ratio = 50
vm.page-cluster = 3
vm.panic_on_oom = 0
vm.percpu_pagelist_fraction = 0
vm.stat_interval = 1
vm.swappiness = 30
vm.user_reserve_kbytes = 108990
vm.vfs_cache_pressure = 100
vm.zone_reclaim_mode = 0

ベストアンサー1

長い話を短く

sudo su
sysctl -w vm.swappiness=10

説明する

私はこのエラーを10/10回再現できるテストシナリオを作成しました。これは、CIを介さずにコマンドラインから直接大きな画像を構築することです。

述べたように、私が知っている解決策は次のとおりです。

echo 1 > /proc/sys/vm/drop_caches

だから私はDirectMapそれを価値観に結び付けようとしています。これらの値はTLB負荷を表し、直接調整できないことがわかっているので、これを使用するための好ましい値である交換性（commutativity）を探してみました。

RHLE 7のドキュメントでは、交換性について説明しています。:

⁠交換性

swappiness 値の範囲は 0 ～ 100 で、システムが匿名メモリまたはページキャッシュをサポートする程度を制御します。高い値は、ファイルシステムのパフォーマンスを向上させるとともに、アクティブではないプロセスをRAMで積極的に置き換えます。値が低いほど、メモリ内のプロセスを交換するのを防ぐことができます。これは通常、I / Oパフォーマンスを犠牲にして待ち時間を短縮します。デフォルトは60です。

警告する
swappiness == 0に設定すると、スワップアウトが非常に積極的に防止されるため、強力なメモリとI / O圧力がOOMシャットダウンのリスクを高めます。

したがって、これを減らすと、メモリ内キャッシュページへの依存度が減少します。私たちが使用しているEC2 Centos 7の画像はデフォルトで30に設定されているので、10に減らすと大きな画像が10/10倍になります。

おすすめ記事