បញ្ជីអត្ថបទ
ចំនួនអ្នកប្រើប្រាស់ក្នុងពេលដំណាលគ្នាដែលម៉ាស៊ីនមេអាចគ្រប់គ្រងបានមិនអាស្រ័យលើចំនួនស្នូលដែលវាមាននោះទេ ប៉ុន្តែអាស្រ័យលើចំនួនអង្គចងចាំដែលដំណើរការនីមួយៗប្រើប្រាស់។
សេចក្តីថ្លែងការណ៍នេះអាចស្តាប់ទៅដូចជាការញុះញង់ ប៉ុន្តែវាគឺជាបទពិសោធន៍ពិត និងឈឺចាប់បំផុតនៅក្នុងឧស្សាហកម្មប្រតិបត្តិការ និងថែទាំ។
ហេតុអ្វីបានជាការចងចាំជាឧបសគ្គចម្បង?
មនុស្សជាច្រើនឃើញ VPS ដែលមាន CPU 8-core និងអង្គចងចាំ 24GB ហើយគិតដោយមិនដឹងខ្លួនថាពួកគេអាចដំណើរការដំណើរការ PHP-FPM រាប់រយបានយ៉ាងងាយស្រួល។
ទោះយ៉ាងណាក៏ដោយ តាមពិតទៅ ការប្រើប្រាស់អង្គចងចាំ RSS នៃដំណើរការ PHP តែមួយច្រើនតែខ្ពស់ដល់ 200MB ។
នេះជាលទ្ធផលដែលទទួលបានតាមរយៈការសាកល្បងជាក់ស្តែងតាមរយៈបន្ទាត់ពាក្យបញ្ជា៖
ps --no-headers -o rss -p $(pgrep php-fpm) | awk '{sum+=$1} END {print sum/NR/1024 " MB"}'
នៅក្នុង ក្របខ័ណ្ឌស្មុគស្មាញ និងបរិស្ថានពហុកម្មវិធីជំនួយរបស់ HestiaCP ជាពិសេសបើគ្មានការបង្កើនប្រសិទ្ធភាព OPcache ទេ ទំហំ 200MB គឺជាបទដ្ឋាន។
នេះមានន័យថា អង្គចងចាំ មិនមែន CPU ទេ គឺជាដែនកំណត់រឹងដែលកំណត់ការដំណើរការស្របគ្នាអតិបរមា។
ឯកសារកំណត់រចនាសម្ព័ន្ធដែលបានណែនាំ (php-fpm.conf)
pm = dynamic
pm.max_children = 80
pm.start_servers = 16
pm.min_spare_servers = 8
pm.max_spare_servers = 24
pm.max_requests = 500
pm.process_idle_timeout = 10s
request_terminate_timeout = 60s
តក្កវិជ្ជាគណនាប៉ារ៉ាម៉ែត្រ និងមូលដ្ឋាននៃការកំណត់
| ប៉ារ៉ាម៉ែត្រកំណត់រចនាសម្ព័ន្ធ | កំណត់តម្លៃ | មូលដ្ឋានគណនាស្នូល និងការរៀបចំ |
|---|---|---|
| pm | dynamic | របៀបថាមវន្តអនុញ្ញាតឱ្យមានការបន្ថែម ឬលុបដំណើរការដែលអាចបត់បែនបានដោយផ្អែកលើតម្រូវការដំណើរការក្នុងពេលដំណាលគ្នា ដោយធ្វើឱ្យមានតុល្យភាពរវាងល្បឿនឆ្លើយតប និងការប្រើប្រាស់អង្គចងចាំ។ |
| pm.max_children | 80 | អង្គចងចាំសរុប 24GB ដកខឺណែលប្រព័ន្ធ និង MySQL/Redisបន្ទាប់ពី Nginx ប្រហែល 16GB នៅសល់សម្រាប់ PHP ។16,384 MB / 200 MB ≈ 81.9ការកំណត់វាទៅ 80 អាចលុបបំបាត់ OOM (Out of Memory) ទាំងស្រុងក្នុងអំឡុងពេលដំណើរការស៊ីសង្វាក់គ្នា។ |
| ម៉ាស៊ីនបម្រើ pm.start | 16 | ការឡើងកម្ដៅជាមុននៅពេលចាប់ផ្ដើមត្រូវបានកំណត់ឱ្យមានចំនួនទ្វេដងនៃចំនួនស្នូល CPU (8 ស្នូល × 2 = 16) ដើម្បីធានាថាសេវាកម្មអាចដោះស្រាយការដំណើរការរួមគ្នាជាមូលដ្ឋានបានភ្លាមៗបន្ទាប់ពីចាប់ផ្ដើមឡើងវិញ។ |
| ម៉ាស៊ីនបម្រើ pm.min_spare_servers | 8 | កំណត់ចំនួនស្នូល CPU ទៅ 8 ស្នូល ដើម្បីធានាថាសំណើថ្មីអាចត្រូវបានឆ្លើយតបនៅពេលណាក៏បានក្នុងអំឡុងពេលចរាចរណ៍ទាប។ |
| ម៉ាស៊ីនបម្រើ pm.max_spare_servers | 24 | កំណត់វាទៅ 3 ដងនៃចំនួនស្នូល CPU (8 ស្នូល × 3 = 24) ដើម្បីរក្សាចំនួនដំណើរការមធ្យមបន្ទាប់ពីចរាចរណ៍ថយចុះ ដើម្បីដោះស្រាយការប្រែប្រួលបន្តិចបន្តួច។ |
| pm.max_requests | 500 | ប្រសិនបើដំណើរការតែមួយឈានដល់មូលដ្ឋានធំ 200MB ការកាត់បន្ថយចំនួនសំណើមកត្រឹម 500 មុនពេលបំផ្លាញ និងសាងសង់ឡើងវិញអាចសម្អាតការលេចធ្លាយអង្គចងចាំដោយប្រយោលបានលឿនជាងមុន។ |
| pm.process_idle_អស់ពេល | 10s | 超出 min_spare_servers ដំណើរការទំនេរត្រូវបានបញ្ចេញដោយស្វ័យប្រវត្តិ ហើយត្រឡប់ទៅអង្គចងចាំប្រព័ន្ធវិញបន្ទាប់ពី 10 វិនាទីដែលគ្មានសំណើ។ |
ការកំណត់ការគាំទ្រសំខាន់ៗ និងការណែនាំអំពីការបង្កើនប្រសិទ្ធភាព
១. យន្តការប្រឆាំងនឹងការស្រវឹងអស់ពេល
request_terminate_timeout = 60s នោះជាគន្លឹះ។
វាអាចបង្ខំឱ្យបញ្ចប់ដំណើរការដែលជាប់គាំងដោយសារតែការជាប់គាំងមូលដ្ឋានទិន្នន័យ ឬការរារាំង API ភាគីទីបី។
ទន្ទឹមនឹងនេះដែរ Nginx fastcgi_read_timeout វាត្រូវតែរក្សាទុកយ៉ាងហោចណាស់ 60 វិនាទី បើមិនដូច្នោះទេអតិថិជននឹងទទួលបានវាមុនអាយុ។ 504 Gateway Timeout។
២. យុទ្ធសាស្ត្រដើម្បីយកឈ្នះលើបញ្ហាកកស្ទះនៃការចងចាំ
ចំនួនដំណើរការកើតឡើងក្នុងពេលដំណាលគ្នាអតិបរមាចំនួន 80 មានន័យថា ក្រោមលក្ខខណ្ឌកើតឡើងក្នុងពេលដំណាលគ្នាខ្លាំង ប្រព័ន្ធអាចដោះស្រាយសំណើ HTTP ថាមវន្តអតិបរមាចំនួន 80 ក្នុងពេលដំណាលគ្នា។
ប្រសិនបើអ្នកចង់បង្កើនសមត្ថភាពបន្ថែមទៀត ការផ្តោតអារម្មណ៍គួរតែផ្តោតលើការកាត់បន្ថយការប្រើប្រាស់អង្គចងចាំក្នុងមួយដំណើរការ។
- បើកដំណើរការ OPcache: មាន
php.iniការកំណត់រចនាសម្ព័ន្ធមធ្យមopcache.enable=1និងopcache.memory_consumption=256ការ caching Bytecode អាចកាត់បន្ថយការប្រើប្រាស់អង្គចងចាំនៃដំណើរការតែមួយពី 200MB មកត្រឹម 60~100MB។ - ការគ្រប់គ្រងសមហេតុផលនៃដែនកំណត់អង្គចងចាំ: 将
php.iniកណ្តាលmemory_limitកំណត់ចំពោះ128M或256Mដើម្បីទប់ស្កាត់ស្គ្រីបមិនប្រក្រតីរបស់បុគ្គលម្នាក់ៗគ្មានដែនកំណត់វាប្រើប្រាស់អង្គចងចាំច្រើន។
នៅពេលដែលការប្រើប្រាស់អង្គចងចាំនៃដំណើរការតែមួយធ្លាក់ចុះដល់ 100MB...pm.max_children វាអាចត្រូវបានធ្វើឱ្យប្រសើរឡើងដោយសុវត្ថិភាពទៅ 150 លើសពីនេះ សមត្ថភាពនៃការធ្វើសមាហរណកម្មបានកើនឡើងស្ទើរតែទ្វេដង។
ទស្សនៈដែលមានអំណាចត្រូវបានលើកឡើង
យោងតាម អនុសាសន៍នៅក្នុង ឯកសារផ្លូវការរបស់ Nginx ៖
"កម្មវិធី FastCGI គួរតែត្រូវបានត្រួតពិនិត្យជានិច្ចជាមួយនឹងការណែនាំអំពីការអស់ពេល ដើម្បីការពារការអស់ធនធាន។"
(ប្រភព៖ ឯកសារ Nginx)
សៀវភៅ ណែនាំ PHP ផ្លូវការ ចែងយ៉ាងច្បាស់ថា៖
"pm.max_children កំណត់ចំនួនអតិបរមានៃដំណើរការកូនដែលត្រូវបង្កើត។ នេះគឺជាការណែនាំដ៏សំខាន់បំផុត។"
(ប្រភព៖ ឯកសារ PHP-FPM)
ទស្សនៈដែលមានសិទ្ធិអំណាចទាំងនេះ គឺស្របគ្នាយ៉ាងល្អឥតខ្ចោះជាមួយនឹងការអនុវត្តរបស់យើង ដែលបង្ហាញថា តក្កវិជ្ជានៃការបង្កើនប្រសិទ្ធភាពមិនត្រឹមតែផ្អែកលើបទពិសោធន៍ប៉ុណ្ណោះទេ ប៉ុន្តែថែមទាំងផ្អែកលើការអនុវត្តល្អបំផុតដែលមានស្តង់ដារផងដែរ។
សេចក្តីសន្និដ្ឋាន៖ ទស្សនៈ និងសម្រង់សម្តីសំខាន់ៗរបស់ខ្ញុំ
នៅក្នុងសេណារីយ៉ូដែលមានការដំណើរការរួមគ្នាខ្ពស់ CPU គឺជាម៉ាស៊ីន អង្គចងចាំគឺជាធុងប្រេងឥន្ធនៈ ហើយ PHP-FPM គឺជាអ្នកចែកចាយកងនាវា។
មិនថាម៉ាស៊ីនមានកម្លាំងខ្លាំងប៉ុណ្ណាទេ ប្រសិនបើធុងប្រេងមិនធំល្មមទេ ក្បួនរថយន្តនឹងមិនទៅឆ្ងាយប៉ុន្មានទេ។
អ្នកជំនាញពិតប្រាកដមិនធ្វើឱ្យប៉ារ៉ាម៉ែត្រអតិបរមាដោយងងឹតងងល់នោះទេ ប៉ុន្តែផ្ទុយទៅវិញគណនាការប្រើប្រាស់អង្គចងចាំនៃដំណើរការនីមួយៗយ៉ាងច្បាស់លាស់ ដើម្បីជៀសវាងការខ្ជះខ្ជាយ និងការលើសចំណុះ។
ខ្លឹមសារនៃការបង្កើនប្រសិទ្ធភាពគឺស្វែងរកតុល្យភាពល្អបំផុតជាមួយនឹងធនធានមានកំណត់។
នេះមិនមែនគ្រាន់តែជាបច្ចេកវិទ្យាទេ ប៉ុន្តែវាក៏ជា ទស្សនវិជ្ជា មួយផងដែរ ។
ដូច្នេះ សូមឈប់ជឿថា "ចំនួនស្នូលកំណត់អ្វីៗគ្រប់យ៉ាង"។ អ្វីដែលពិតជាកំណត់ដែនកំណត់នៃការធ្វើដំណាលគ្នាគឺការគ្រប់គ្រងរបស់អ្នកលើអង្គចងចាំ។
ចាត់វិធានការ និងបង្កើនប្រសិទ្ធភាព VPS របស់អ្នកឱ្យអស់ពីសក្តានុពល ដោយទាញយកអត្ថប្រយោជន៍ច្រើនបំផុតពីរាល់ដំណក់នៃការចងចាំ។
សង្ឃឹមថា អត្ថបទ "8-core 24GB VPS អស់អង្គចងចាំហើយឬនៅ? ការលៃតម្រូវខ្លាំងនៃអាងដំណើរការ PHP-FPM ក្រោម HestiaCP" ដែលបានចែករំលែកនៅលើ ប្លក់របស់ Chen Weiliang ( https://www.chenweiliang.com/ ) នឹងមានប្រយោជន៍សម្រាប់អ្នក។
សូមចែករំលែកតំណភ្ជាប់អត្ថបទនេះ៖ https://www.chenweiliang.com/cwl-34509.html