ホスティング プロバイダーの目標の XNUMX つは、エンド ユーザーに高品質のサービスを提供するために、既存の機器を最大限に活用することです。 エンドサーバーのリソースは常に限られていますが、ホストされるクライアント サービスの数 (この場合は VPS について話しています) は大幅に異なる場合があります。 木に登る方法と切り口の下でハンバーガーを食べる方法について読んでください。
クライアントがそれをまったく感じないような方法でノード上の VPS を圧縮することは、ホスティング プロバイダーの経済的パフォーマンスを向上させるのに非常に役立ちます。 もちろん、ノードがコンテナでいっぱいになっても継ぎ目でバーストしてはならず、負荷の急増はすべてのクライアントに即座に感じられます。
XNUMX つのノードでホストできる VPS の数は、次のような明らかな要因によって決まります。
1. ノード自体のハードウェアの特徴
2.VPSのサイズ
3. VPS の負荷の性質
4. 密度の最適化を支援するソフトウェア技術
今回は、Virtuozzo で Pfcache テクノロジを使用した経験を共有します。
ここでは 6 番目のブランチを使用しますが、ここで述べたことはすべて 7 番目のブランチにも当てはまります。
– コンテナ内の IOPS と RAM の重複排除を支援する Virtuozzo メカニズム。コンテナ内の同一のファイルを別の共通領域に割り当てます。
実際、それは次のもので構成されます。
1. カーネルコード
2. ユーザー空間の悪魔
3. ユーザー空間ユーティリティ
ノード側では、ノード上のすべての VPS によって直接使用されるファイルが作成されるセクション全体を割り当てます。 このセクションにはブロックプループデバイスが搭載されています。 その後、コンテナーが起動すると、このセクションの参照を受け取ります。
[root@pcs13 ~]# cat /proc/mounts
...
/dev/ploop62124p1 /vz/pfcache ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12 0 0
...
/dev/ploop22927p1 /vz/root/418 ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,pfcache_csum,pfcache=/vz/pfcache 0 0
/dev/ploop29642p1 /vz/root/264 ext4 rw,relatime,barrier=1,data=ordered,balloon_ino=12,pfcache_csum,pfcache=/vz/pfcache 0 0
...
XNUMX つのノード上のファイル数のおおよその統計を次に示します。
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
pfcache の原理は次のとおりです。
• ユーザー空間デーモン Pfcached は、ファイルの sha-1 ハッシュをこのファイルの xattr 属性に書き込みます。 すべてのファイルが処理されるわけではなく、/usr、/bin、/usr/sbin、/sbin、/lib、/lib64 ディレクトリ内のファイルのみが処理されます。
• これらのディレクトリ内のファイルは「共有」され、複数のコンテナによって使用される可能性が最も高くなります。
• Pfcached は、カーネルからのファイルの読み取りに関する統計を定期的に収集して分析し、ファイルが頻繁に使用される場合はキャッシュに追加します。
• これらのディレクトリは異なる場合があり、構成ファイルで構成されます。
• ファイルを読み込むときは、xattr 拡張属性に指定されたハッシュが含まれているかどうかがチェックされます。 含まれている場合は、コンテナ ファイルの代わりに「一般」ファイルが開かれます。 この置換はコンテナ コードに気づかれずに行われ、カーネル内に隠蔽されます。
• ファイルに書き込む場合、ハッシュは無効になります。 したがって、次回それを開くときは、キャッシュではなくコンテナ ファイル自体が開かれます。
/vz/pfcache の共有ファイルをページ キャッシュに保持することで、このキャッシュ自体の節約と IOPS の節約を実現します。ディスクから XNUMX 個のファイルを読み取る代わりに、XNUMX 個を読み取り、すぐにページ キャッシュに移動します。
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
ファイルの VMA リストは単一のままであり (メモリの重複が排除されます)、ディスクから読み取られる頻度が減ります (iops が節約されます)。 私たちの共通資金は SSD 上にあり、速度がさらに向上します。
/bin/bash ファイルをキャッシュする例:
[root@pcs13 ~]# ls -li /vz/root/2388/bin/bash
524650 -rwxr-xr-x 1 root root 1021112 Oct 7 2018 /vz/root/2388/bin/bash
[root@pcs13 ~]# pfcache dump /vz/root/2388 | grep 524650
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 i:524650 g:1357611108 f:CP
[root@pcs13 ~]# sha1sum /vz/root/2388/bin/bash
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 /vz/root/2388/bin/bash
[root@pcs13 /]# getfattr -ntrusted.pfcache /vz/root/2388/bin/bash
# file: vz/root/2388/bin/bash
trusted.pfcache="8e3aa19fdc42e87659746f6dc8ea3af74ab30362"
[root@pcs13 ~]# sha1sum /vz/pfcache/8e/3aa19fdc42e87659746f6dc8ea3af74ab30362
8e3aa19fdc42e87659746f6dc8ea3af74ab30362 /vz/pfcache/8e/3aa19fdc42e87659746f6dc8ea3af74ab30362
使用効率を計算します .
このスクリプトはノード上のすべてのコンテナを調べて、各コンテナのキャッシュされたファイルを計算します。
[root@pcs16 ~]# /pcs/distr/pfcache-examine.pl
...
Pfcache cache uses 831 MB of memory
Total use of pfcached files in containers is 39837 MB of memory
Pfcache effectiveness: 39006 MB
したがって、メモリから約 40 GB のファイルをコンテナに保存し、それらはキャッシュからロードされます。
このメカニズムがさらにうまく機能するには、ノード上に最も「同一の」VPS を配置する必要があります。 たとえば、ユーザーが root アクセス権を持たず、デプロイされたイメージの環境が構成されているものです。
構成ファイルを通じて pfcache を調整できます
/etc/vz/pfcache.conf
MINSIZE、MAXSIZE – キャッシュの最小/最大ファイル サイズ
TIMEOUT – キャッシュ試行間のタイムアウト
パラメータの完全なリストを表示できます .
出所： habr.com