Salah satu matlamat penyedia pengehosan adalah untuk memaksimumkan penggunaan peralatan sedia ada untuk menyediakan perkhidmatan berkualiti tinggi kepada pengguna akhir. Sumber pelayan akhir sentiasa terhad, tetapi bilangan perkhidmatan pelanggan yang dihoskan, dan dalam kes kami, kita bercakap tentang VPS, boleh berbeza dengan ketara. Baca tentang cara memanjat pokok dan makan burger di bawah potongan.
Memampatkan VPS pada nod dengan cara yang pelanggan tidak merasakannya sama sekali sangat membantu meningkatkan prestasi ekonomi mana-mana penyedia pengehosan. Sudah tentu, nod tidak boleh pecah pada jahitan jika ia penuh dengan bekas, dan sebarang lonjakan beban segera dirasai oleh semua pelanggan.
Berapa banyak VPS boleh dihoskan pada satu nod bergantung pada banyak faktor, yang jelas seperti:
1. Ciri-ciri perkakasan nod itu sendiri
2. Saiz VPS
3. Sifat beban pada VPS
4. Teknologi perisian yang membantu mengoptimumkan ketumpatan
Dalam kes ini, kami akan berkongsi pengalaman kami menggunakan teknologi Pfcache untuk Virtuozzo.
Kami menggunakan cawangan ke-6, tetapi semua yang dikatakan juga benar untuk cawangan ke-7.
β mekanisme Virtuozzo yang membantu menyahduplikasi IOPS dan RAM dalam bekas, memperuntukkan fail yang sama dalam bekas ke dalam kawasan umum yang berasingan.
Malah ia terdiri daripada:
1. Kod kernel
2. Syaitan ruang pengguna
3. Utiliti ruang pengguna
Di bahagian nod, kami memperuntukkan keseluruhan bahagian di mana fail akan dibuat yang akan digunakan terus oleh semua VPS pada nod. Peranti blok ploop dipasang di bahagian ini. Kemudian, apabila bekas bermula, ia menerima rujukan untuk bahagian ini:
[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
...
Berikut ialah statistik anggaran bilangan fail pada salah satu nod kami:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Prinsip pfcache adalah seperti berikut:
β’ Daemon ruang pengguna Pfcached menulis cincangan sha-1 fail kepada atribut xattr bagi fail ini. Tidak semua fail diproses, tetapi hanya dalam direktori /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
β’ Kemungkinan besar fail dalam direktori ini akan "dikongsi" dan akan digunakan oleh beberapa bekas;
β’ Pfcached secara berkala mengumpul statistik tentang membaca fail daripada kernel, menganalisisnya dan menambah fail ke cache jika ia kerap digunakan;
β’ Direktori ini mungkin berbeza dan dikonfigurasikan dalam fail konfigurasi.
β’ Apabila membaca fail, ia diperiksa sama ada ia mengandungi cincang yang ditentukan dalam atribut lanjutan xattr. Jika ia mengandungi, fail "umum" dibuka dan bukannya fail bekas. Penggantian ini berlaku tanpa disedari oleh kod bekas dan tersembunyi dalam kernel;
β’ Apabila menulis pada fail, cincangan tidak sah. Oleh itu, apabila anda membukanya seterusnya, fail bekas itu sendiri akan dibuka, dan bukan cachenya.
Dengan menyimpan fail kongsi daripada /vz/pfcache dalam cache halaman, kami mencapai penjimatan dalam cache ini sendiri, serta penjimatan dalam IOPS. Daripada membaca sepuluh fail dari cakera, kami membaca satu, yang segera pergi ke cache halaman.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
Senarai VMA untuk fail kekal tunggal (kami menyahgandakan memori) dan kurang kerap dibaca dari cakera (menjimatkan iops). Dana biasa kami terletak pada SSD - keuntungan tambahan dalam kelajuan.
Contoh untuk menyimpan fail /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
Kami mengira kecekapan penggunaan .
Skrip ini melalui semua bekas pada nod, mengira fail cache setiap bekas.
[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
Oleh itu, dari ingatan kami menyimpan kira-kira 40 gigabait fail dalam bekas; ia akan dimuatkan daripada cache.
Untuk mekanisme ini berfungsi dengan lebih baik, anda perlu meletakkan VPS yang paling "sama" pada nod. Sebagai contoh, mereka yang pengguna tidak mempunyai akses root dan persekitaran daripada imej yang digunakan dikonfigurasikan.
Anda boleh menala pfcache melalui fail konfigurasi
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE β saiz fail minimum/maksimum untuk caching
TIMEOUT β tamat masa antara percubaan caching
Anda boleh melihat senarai penuh parameter .
Sumber: www.habr.com