Ang isa sa mga layunin ng hosting provider ay upang i-maximize ang paggamit ng mga umiiral na kagamitan upang makapagbigay ng mataas na kalidad na serbisyo sa mga end user. Ang mga mapagkukunan ng mga end server ay palaging limitado, ngunit ang bilang ng mga naka-host na serbisyo ng kliyente, at sa aming kaso pinag-uusapan natin ang tungkol sa VPS, ay maaaring mag-iba nang malaki. Basahin ang tungkol sa kung paano umakyat sa puno at kumain ng burger sa ilalim ng hiwa.
Ang pag-compact ng VPS sa isang node sa paraang hindi ito nararamdaman ng mga kliyente ay lubos na nakakatulong upang mapataas ang pang-ekonomiyang pagganap ng anumang hosting provider. Siyempre, ang isang node ay hindi dapat pumutok sa mga tahi kung ito ay masikip na puno ng mga lalagyan, at ang anumang surge sa load ay agad na nararamdaman ng lahat ng mga kliyente.
Gaano karaming mga VPS ang maaaring i-host sa isang node ay depende sa maraming mga kadahilanan, tulad ng mga halatang tulad ng:
1. Mga katangian ng hardware ng node mismo
2. Laki ng VPS
3. Kalikasan ng load sa VPS
4. Mga teknolohiya ng software na tumutulong sa pag-optimize ng density
Sa kasong ito, ibabahagi namin ang aming karanasan sa paggamit ng teknolohiyang Pfcache para sa Virtuozzo.
Ginagamit namin ang ika-6 na sangay, ngunit ang lahat ng sinabi ay totoo din para sa ika-7.
β isang mekanismo ng Virtuozzo na tumutulong sa pag-deduplicate ng IOPS at RAM sa mga container, na naglalaan ng magkaparehong mga file sa mga container sa isang hiwalay na common area.
Sa katunayan ito ay binubuo ng:
1. Kernel code
2. User-space demonyo
3. Mga utility ng user-space
Sa gilid ng node, naglalaan kami ng isang buong seksyon kung saan malilikha ang mga file na direktang gagamitin ng lahat ng VPS sa node. Ang isang block ploop device ay naka-mount sa seksyong ito. Pagkatapos, kapag nagsimula ang lalagyan, makakatanggap ito ng reference para sa seksyong ito:
[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
...
Narito ang mga tinatayang istatistika sa bilang ng mga file sa isa sa aming mga node:
[root@pcs13 ~]# find /vz/pfcache -type f | wc -l
45851
[root@pcs13 ~]# du -sck -h /vz/pfcache
2.4G /vz/pfcache
2.4G total
Ang prinsipyo ng pfcache ay ang mga sumusunod:
β’ Ang user-space daemon na si Pfcached ay nagsusulat ng sha-1 hash ng file sa xattr attribute ng file na ito. Hindi lahat ng file ay pinoproseso, ngunit sa mga direktoryo lamang na /usr, /bin, /usr/sbin, /sbin, /lib, /lib64
β’ Malamang na ang mga file sa mga direktoryo na ito ay "ibabahagi" at gagamitin ng ilang mga lalagyan;
β’ Pana-panahong kinokolekta ng Pfcached ang mga istatistika sa pagbabasa ng mga file mula sa kernel, sinusuri ito, at nagdaragdag ng mga file sa cache kung madalas itong ginagamit;
β’ Maaaring iba ang mga direktoryo na ito at naka-configure sa mga configuration file.
β’ Kapag nagbabasa ng file, sinusuri kung naglalaman ito ng tinukoy na hash sa xattr extended attributes. Kung naglalaman ito, ang "pangkalahatan" na file ay bubuksan sa halip na ang container file. Ang pagpapalit na ito ay nangyayari nang hindi napapansin ng container code at nakatago sa kernel;
β’ Kapag sumusulat sa isang file, ang hash ay hindi wasto. Kaya, sa susunod na buksan mo ito, ang container file mismo ang bubuksan, at hindi ang cache nito.
Sa pamamagitan ng pag-iingat ng mga nakabahaging file mula sa /vz/pfcache sa cache ng pahina, nakakamit namin ang mga matitipid sa cache na ito mismo, pati na rin ang mga pagtitipid sa IOPS. Sa halip na magbasa ng sampung file mula sa disk, nagbabasa kami ng isa, na agad na napupunta sa cache ng pahina.
struct inode {
...
struct file *i_peer_file;
...
};
struct address_space {
...
struct list_head i_peer_list;
...
}
Ang listahan ng VMA para sa file ay nananatiling iisa (na-deduplicate namin ang memorya) at binabasa mula sa disk nang mas madalas (nagse-save ng mga iops). Ang aming karaniwang pondo ay matatagpuan sa isang SSD - isang karagdagang pakinabang sa bilis.
Halimbawa para sa pag-cache ng /bin/bash file:
[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
Kinakalkula namin ang kahusayan ng paggamit .
Ang script na ito ay dumaan sa lahat ng mga lalagyan sa node, na kinakalkula ang mga naka-cache na file ng bawat lalagyan.
[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
Kaya, mula sa memorya ay nagse-save kami ng mga 40 gigabytes ng mga file sa mga lalagyan; mai-load ang mga ito mula sa cache.
Para gumana nang mas mahusay ang mekanismong ito, kinakailangang ilagay ang pinaka "magkaparehong" VPS sa node. Halimbawa, ang mga kung saan ang user ay walang root access at kung saan ang kapaligiran mula sa naka-deploy na imahe ay na-configure.
Maaari mong ibagay ang pfcache sa pamamagitan ng config file
/etc/vz/pfcache.conf
MINSIZE, MAXSIZE β minimum/maximum na laki ng file para sa pag-cache
TIMEOUT β timeout sa pagitan ng mga pagtatangka sa pag-cache
Maaari mong tingnan ang buong listahan ng mga parameter .
Pinagmulan: www.habr.com