コンテナを高速化する方法：OpenVZの調整

OpenVZは、Linuxカーネル用のコンテナー仮想化テクノロジーのOpenSource実装であり、OpenVZカーネルを備えた単一システム上で、さまざまなLinuxディストリビューションを含む多くの仮想環境で実行できます。 密度、弾力性、RAMサイズの要件、応答速度などの多くのパフォーマンスインジケータの機能（コンテナ仮想化は、鉄ではなくカーネルレベル）によります。 -他の仮想化テクノロジーよりもうまく機能します。 たとえば、 ここでは、従来のハイパーバイザー仮想化システムとのOpenVZパフォーマンスの比較を見ることができます。 しかし、これに加えて、LinuxとOpenVZには微調整のためのオプションがたくさんあります。

この記事では、OpenVZシステム全体のパフォーマンスを改善できる、OpenVZカーネルコンテナーの重要な構成オプションを検討します。

一般設定

コンテナのパフォーマンスに影響する主な設定は、メモリとプロセッサの消費の制限です。 ほとんどの場合、割り当てられたメモリとプロセッサの量を増やすと、たとえばWebサーバーやデータベースサーバーなどのカスタムアプリケーションのコンテナのパフォーマンスが向上します。



コンテナに割り当てられた物理メモリにグローバルな制限を設定するには、たとえば--ramオプションを指定するだけです。

# vzctl set 100 --ram 4G --save
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

コンテナの過小評価された制限は、カーネルまたはアプリケーションのどこかでメモリを割り当てることに失敗することが非常に多いため、コンテナを使用する場合、/ proc / user_beancountersファイルの内容を監視することは非常に役立ちます。 failcnt列のゼロ以外の値は、制限の一部が小さすぎることを意味し、コンテナのワーキングセットを減らす（たとえば、apacheまたはpostgresqlサーバースレッドの数を減らす）か、-ramオプションを使用してメモリ制限を増やす必要があります。 / proc / user_beancountersファイルを便利に監視するには、vzubcユーティリティを使用できます。これにより、たとえば、failcntに近いカウンターのみを監視したり、一定の周期で読み取り値を更新したりできます（トップライクモード）。 vzubcユーティリティの詳細については、 こちらをご覧ください 。



物理メモリに制限を設定することに加えて、コンテナのスワップサイズに制限を設定することをお勧めします。 スワップコンテナのサイズを調整するには、vzctlコマンドの--swapオプションを使用します。

 # vzctl set 100 --ram 4G --swap 8G --save
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

--ram値と--swap値の合計は、コンテナが使用できるメモリの最大量です。 コンテナの--ram制限に達すると、コンテナプロセスに属するメモリページは、いわゆる「仮想スワップ（VSwap）」にプッシュされ始めます。 この場合、実際のディスクI / Oは存在せず、コンテナのパフォーマンスは人為的に低下し、実際のスワッピングの効果が生じます。



コンテナを設定する場合、すべてのコンテナのRAM +スワップの合計が、ホストノードのRAM +スワップの合計を超えないようにすることをお勧めします。 設定を確認するには、vzoversellユーティリティを使用できます。



コンテナーで使用可能なプロセッサーの最大数を制御するには、-cpusオプションを使用する必要があります。次に例を示します。

 # vzctl set 100 --cpus 4 --save
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

新しいコンテナを作成するとき、このコンテナのプロセッサの数は制限されておらず、サーバーのすべてのCPUリソースを使用します。 したがって、複数のコンテナを持つシステムの場合、各コンテナに割り当てられたタスクに応じて、各コンテナのプロセッサ数に制限を設定することは理にかなっています。 また、-cpulimitオプションを使用してCPUをパーセント（またはメガヘルツ）で制限し、-cpuunitsオプションを使用して重み、つまりコンテナの優先度を管理することも役立つ場合があります。

メモリからのオーバーコミット

OpenVZコアにより、すべてのコンテナは、ホストで使用可能な物理メモリの合計よりも大きなメモリを割り当てることができます。 この状況はメモリオーバーコミットと呼ばれ、この場合、カーネルはメモリを動的に管理し、コンテナ間でメモリのバランスを取ります。これは、コンテナが使用を許可したメモリがコンテナによって必要とされず、カーネルが自由裁量で制御できるためです。 メモリからオーバーコミットすると、カーネルはさまざまなキャッシュ（ページキャッシュ、デントリキャッシュ）を効果的に管理し、設定されたメモリ制限に比例してコンテナ内でそれらを削減しようとします。 たとえば、セキュリティを向上させるために、フロントエンド、バックエンド、およびデータベースで構成される負荷の高いWebサイトのサービスを互いに分離する場合、それらを別々のコンテナーに入れることができますが、同時に各ホストで利用可能な最大数を選択しますメモリ量、たとえば：

 # vzctl set 100 --ram 128G --save # vzctl set 101 --ram 128G --save # vzctl set 102 --ram 128G --save
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この場合、メモリ管理の観点から見ると、サービスが同じホストで実行されていたときと状況は変わらず、メモリバランシングは可能な限り効率的になります。 静的Webサイトデータ用の大きなページキャッシュ用のフロントエンドコンテナーや、データベースが含まれるコンテナー用に-データベース自体用の大きなキャッシュキャッシュ用に、どのコンテナーにメモリを追加する必要があるかを考える必要はありません。 カーネルはすべてを自動的にバランスさせます。



オーバーコミットにより、カーネルはコンテナ間で可能な限り効率的にメモリのバランスを取ることができますが、特定の不快な特性もあります。 割り当てられた匿名メモリの合計量、つまり、すべてのコンテナのすべてのプロセスの合計ワーキングセットがホストの合計メモリサイズに近づくと、プロセスまたはカーネルによって新しいメモリを割り当てようとすると、グローバルな「メモリ不足」例外が発生し、OOMキラーが強制終了しますシステム内のプロセスの1つ。 このような例外がホストまたはコンテナで発生したかどうかを確認するには、次のコマンドを使用できます。

 # dmesg | grep oom [3715841.990200] 645043 (postmaster) invoked oom-killer in ub 600 generation 0 gfp 0x2005a [3715842.557102] oom-killer in ub 600 generation 0 ends: task died
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

OOMキラーは、メモリを割り当てようとした同じコンテナ内のプロセスを必ずしも強制終了するわけではないことに注意することが重要です。 OOM-killerの動作を制御するには、次のコマンドを使用します：

 # vzctl set 100 --oomguarpages 2G --save
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

指定した制限内でコンテナプロセスの整合性を保証する制限を設定できます。 したがって、重要なサービスを実行しているコンテナの場合、この制限をメモリ制限に等しく設定できます。

CPUのオーバーコミット

メモリの場合と同様に、プロセッサによるオーバーコミットにより、ホスト上の論理プロセッサの総数を超えるプロセッサの総数をコンテナに割り当てることができます。 また、メモリの場合と同様に、プロセッサによるオーバーコミットにより、システム全体のパフォーマンスが最も効果的になります。 たとえば、フロントエンド、バックエンド、データベースの3つのコンテナに「レイアウト」された同じWebサーバーの場合、各コンテナに無制限のCPUを設定し、最大のシステムパフォーマンスを実現することもできます。 繰り返しますが、カーネル自体は、どのコンテナからどのプロセッサにプロセッサ時間を割り当てるかを決定します。



メモリとは異なり、プロセッサは「弾力性のある」リソースです。つまり、CPUの不足は、一部のアクティブなプロセスの速度を落とすことを除いて、システムで例外やエラーを引き起こしません。 したがって、プロセッサによるオーバーコミットの使用は、メモリからのオーバーコミットよりもシステムをオーバークロックする安全な方法です。 プロセッサのオーバーコミットの唯一のマイナスの影響は、コンテナにプロセッサ時間を割り当てる際の誠実性の原則に違反する可能性があることです。これは、たとえば、有料のプロセッサ時間よりも少ないクライアントを受け取るVPSホスティングクライアントにとっては悪い場合があります。 プロセッサ時間の正直な分布を維持するには、vzctlコマンドの--cpuunitsオプションを使用して、支払われたプロセッサ時間に応じてコンテナの「重み」を設定する必要があります（詳細については、 こちらを参照してください）。

NUMAホスト上のコンテナーの最適化

NUMA（Non-Uniform Memory Access）を備えたホストでコンテナーを実行する場合、コンテナープロセスが1つのNUMAノードで実行され、これらのプロセスの一部（またはすべてのメモリー）が別のNUMAノードに割り当てられた可能性があります。 この場合、各メモリアクセスはローカルNUMAノードのメモリアクセスよりも遅くなり、減速係数はノード間の距離に依存します。 Linuxカーネルはこの状況を防止しようとしますが、ローカルNUMAノードでのコンテナーの実行を保証するために、コンテナーごとにCPUマスクを設定できます。これにより、コンテナープロセスが実行できるプロセッサーのセットが制限されます。



numactlコマンドを使用して、ホストで使用可能なNUMAノードを表示できます。

  ＃numactl -H
使用可能：2ノード（0-1）
ノード0 cpus：0 1 2 3
ノード0サイズ：16351 MB
ノード0空き：1444 MB
ノード1 cpus：4 5 6 7
ノード1のサイズ：16384 MB
ノード1空き：10602 MB
ノード距離：
ノード0 1
   0:10 21
   1:21 10 

この例では、ホストに2つのNUMAノードがあり、各ノードには4つのプロセッサコアと16GBのメモリがあります。



コンテナのプロセッサセットに制限を設定するには、vzctlコマンドを使用します。

 # vzctl set 100 --cpumask 0-3 --save # vzctl set 101 --cpumask 4-7 --save
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この例では、コンテナ100がプロセッサ0〜3、コンテナ101が4〜7でのみ実行できるようにしました。たとえば、コンテナ100のプロセスが既にNUMAノード1にメモリを割り当てている場合、このメモリへのアクセスはすべてローカルメモリへのアクセスよりも遅くなります。 したがって、これらのコマンドを実行した後にコンテナを再起動することをお勧めします。



新しいvzctl 4.8リリースでは、--nodemaskオプションが登場しました。これにより、このノードのプロセッサのリストを指定せずに、コンテナを特定のNUMAノードに接続できますが、NUMAノード番号のみで動作します。



このアプローチでは、プロセススケジューラがシステムプロセッサ間で負荷を分散する能力が制限されることに注意してください。これにより、プロセッサが大幅にオーバーコミットされた場合、速度が低下する可能性があります。

コンテナでのfsync動作の制御

ご存じのように、データがディスクに確実に書き込まれるようにするには、アプリケーションは変更された各ファイルに対してfsync（）システムコールを行う必要があります。 このシステムコールは、ファイルデータをライトバックキャッシュからディスクに書き込み、ディスクキャッシュから永続的な不揮発性メディアへのデータのフラッシュを開始します。 同時に、アプリケーションがライトバックキャッシュ（いわゆる直接I / O）をバイパスしてディスクにデータを書き込む場合でも、データがディスクのキャッシュからフラッシュされることを保証するには、このシステムコールが必要です。



fsync（）システムコールを頻繁に実行すると、ディスクサブシステムの速度が著しく低下する可能性があります。 平均的なハードドライブは30〜50の同期/秒に対応しています。



さらに、コンテナのすべてまたは一部について、データ記録の厳密な保証は不要であり、ハードウェア障害が発生した場合のデータの一部の損失は重要ではないことがよく知られています。 そのような場合、OpenVZカーネルは、コンテナのすべてまたは一部に対するfsync（）/ fdatasync（）/ sync（）要求を無視する機能を提供します。 ファイル/ proc / sys / fs / fsync-enableを使用して、カーネルの動作をカスタマイズできます。 ホストノードで構成されている場合、このファイルの可能な値（グローバル設定）：

   0（FSYNC_NEVER）fsync（）/ fdatasync（）/ sync（）コンテナからのリクエストは無視されます
   1（FSYNC_ALWAYS）fsync（）/ fdatasync（）/ sync（）コンテナからのリクエストは通常​​どおり動作しますが、 
                        ホストマシンのすべてのファイルシステム上のすべてのiノードのデータが書き込まれます
   2（FSYNC_FILTERED）fsync（）/ fdatasync（）コンテナからのリクエストは通常​​どおり動作しますが、
                        コンテナからのsync（）要求は、コンテナファイルのみに影響します（デフォルト値）

特定のコンテナ内で構成されている場合、このファイルの可能な値：

   0このコンテナからのfsync（）/ fdatasync（）/ sync（）要求は無視されます 
   2ホストノードにインストールされたグローバル設定を使用する（デフォルト値）

これらの設定はサーバーのディスクサブシステムを大幅に高速化できるという事実にもかかわらず、慎重かつ選択的に使用する必要があります。 fsync（）を無効にすると、ハードウェア障害が発生した場合にデータが失われる可能性があります。

コンテナでの直接I / O動作の制御

デフォルトでは、O_DIRECTフラグなしで開かれたすべてのファイルへの書き込みは、ライトバックキャッシュを介して行われます。 これにより、アプリケーションのディスクへのデータ書き込みのレイテンシー（レイテンシー）が削減されるだけでなく（ディスクへの実際の書き込みを待たずにデータがライトバックキャッシュにコピーされるとすぐにwrite（）システムコールが終了します）、カーネルI / Oスケジューラーも許可されますプロセス間でディスクリソースをより効率的に分散し、アプリケーションからのI / O要求をグループ化します。



同時に、データベースなどのいくつかのカテゴリのアプリケーションは、大規模な順次I / O要求を実行することにより、データの記録を効果的に管理します。 したがって、このようなアプリケーションは多くの場合、O_DIRECTフラグを使用してファイルを開きます。これは、ユーザーアプリケーションメモリから直接、ライトバックキャッシュをバイパスして、そのようなファイルにデータを書き込むようカーネルに指示します。 ホストで実行されている単一のデータベースの場合、データベースからのI / O要求はすでに最適に構成されており、ユーザーアプリケーションからライトバックキャッシュへのメモリの追加コピーが必要ないため、このアプローチはキャッシュ経由で書き込むよりも効率的です。



複数のコンテナが同じホスト上のデータベースで動作する場合、LinuxカーネルのI / OスケジューラはDirect I / Oを使用するアプリケーション間でディスクリソースを最適に分配できないため、この仮定は誤りです。 したがって、デフォルトでは、コンテナのOpenVZ Direct I / Oカーネルはオフになり、すべてのデータはライトバックキャッシュを介して書き込まれます。 これにより、ユーザーアプリケーションからライトバックキャッシュへのメモリの追加コピーという形で小さなオーバーヘッドが発生しますが、カーネルI / Oスケジューラはディスクリソースをより効率的に割り当てることができます。



ホストにそのような状況が存在しないことが事前にわかっている場合は、追加のオーバーヘッドを回避し、コンテナのすべてまたは一部に直接I / Oの使用を許可できます。 ファイル/ proc / sys / fs / odirect_enableを使用して、カーネルの動作をカスタマイズできます。 ホストノードで構成されている場合、このファイルの可能な値（グローバル設定）：

   0コンテナのO_DIRECTフラグは無視され、すべての記録はライトバックキャッシュを介して行われます（デフォルト値）
   1コンテナ内のO_DIRECTフラグは通常どおり機能します

特定のコンテナ内で構成されている場合、このファイルの可能な値：

   0このコンテナのO_DIRECTフラグは無視され、すべての記録はライトバックキャッシュを介して行われます
  このコンテナのO_DIRECTフラグは通常どおり機能します
   2グローバル設定を使用する（デフォルト値）

おわりに

一般に、Linuxカーネル全体、特にOpenVZは、特定のユーザータスクのパフォーマンスを微調整するための多数のオプションを提供します。 OpenVZに基づく仮想化により、柔軟なリソース管理とさまざまな設定により、最高のパフォーマンスを実現できます。 この記事では、コンテナ固有の設定のごく一部のみを紹介しました。 特に、CPUUNITS / CPULIMIT / CPUSの3つのパラメーターと、それらが互いにどのように影響するかについては書いていません。 しかし、私はこれでコメントでもっと多くを説明する準備ができています。

詳細については、vzctlのマニュアルページとインターネット上の膨大なリソース（openvz.livejournal.comなど）を参照してください。