ការកំណត់រចនាសម្ព័ន្ធ Linux Kernel Options ដើម្បីបង្កើនប្រសិទ្ធភាព PostgreSQL

ការអនុវត្ត PostgreSQL ល្អបំផុតអាស្រ័យលើប៉ារ៉ាម៉ែត្រប្រព័ន្ធប្រតិបត្តិការដែលបានកំណត់យ៉ាងត្រឹមត្រូវ។ ការកំណត់ខឺណែល OS ដែលបានកំណត់រចនាសម្ព័ន្ធមិនល្អអាចបណ្តាលឱ្យដំណើរការម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យខ្សោយ។ ដូច្នេះ វាជាការចាំបាច់ដែលការកំណត់ទាំងនេះត្រូវបានកំណត់រចនាសម្ព័ន្ធដោយយោងទៅតាមម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ និងបន្ទុកការងាររបស់វា។ នៅក្នុងការប្រកាសនេះ យើងនឹងពិភាក្សាអំពីប៉ារ៉ាម៉ែត្រខឺណែលលីនុចសំខាន់ៗមួយចំនួនដែលអាចប៉ះពាល់ដល់ដំណើរការម៉ាស៊ីនមេមូលដ្ឋានទិន្នន័យ និងរបៀបកំណត់រចនាសម្ព័ន្ធពួកវា។

SHMMAX / SHMALL

SHMMAX គឺជាប៉ារ៉ាម៉ែត្រខឺណែលដែលប្រើដើម្បីកំណត់ទំហំអតិបរមានៃផ្នែកអង្គចងចាំដែលបានចែករំលែកតែមួយដែលដំណើរការលីនុចអាចបែងចែកបាន។ មុនពេលកំណែ 9.2 PostgreSQL បានប្រើប្រព័ន្ធ V (SysV) ដែលតម្រូវឱ្យមានការកំណត់ SHMMAX ។ បន្ទាប់ពី 9.2, PostgreSQL បានប្តូរទៅអង្គចងចាំដែលបានចែករំលែក POSIX ។ ដូច្នេះឥឡូវនេះ ប៊ីតតិចនៃអង្គចងចាំដែលបានចែករំលែករបស់ System V ត្រូវបានទាមទារ។

មុនកំណែ 9.3 SHMMAX គឺជាប៉ារ៉ាម៉ែត្រខឺណែលសំខាន់បំផុត។ តម្លៃ SHMMAX ត្រូវបានបញ្ជាក់ជាបៃ។

ស្រដៀងគ្នានេះដែរ SHMALL គឺជាប៉ារ៉ាម៉ែត្រខឺណែលមួយផ្សេងទៀតដែលប្រើដើម្បីកំណត់
បរិមាណពេញប្រព័ន្ធនៃទំព័រសតិដែលបានចែករំលែក។ ដើម្បីមើលតម្លៃ SHMMAX, SHMALL ឬ SHMMIN បច្ចុប្បន្ន សូមប្រើពាក្យបញ្ជា អាយភីអេស.

SHM * ព័ត៌មានលម្អិត - លីនុច

$ ipcs -lm

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 1073741824
max total shared memory (kbytes) = 17179869184
min seg size (bytes) = 1

SHM* ព័ត៌មានលម្អិត - MacOS X

$ ipcs -M
IPC status from  as of Thu Aug 16 22:20:35 PKT 2018
shminfo:
	shmmax: 16777216	(max shared memory segment size)
	shmmin:       1	(min shared memory segment size)
	shmmni:      32	(max number of shared memory identifiers)
	shmseg:       8	(max shared memory segments per process)
	shmall:    1024	(max amount of shared memory in pages)

PostgreSQL ប្រើ ប្រព័ន្ធ V IPC ដើម្បីបែងចែកការចងចាំដែលបានចែករំលែក។ ប៉ារ៉ាម៉ែត្រនេះគឺជាប៉ារ៉ាម៉ែត្រខឺណែលសំខាន់បំផុតមួយ។ នៅពេលណាដែលអ្នកទទួលបានសារកំហុសខាងក្រោម វាមានន័យថាអ្នកមានកំណែ PostgreSQL ចាស់ ហើយតម្លៃ SHMMAX របស់អ្នកគឺទាបណាស់។ អ្នក​ប្រើ​ត្រូវ​បាន​គេ​រំពឹង​ថា​នឹង​កែ​សម្រួល​និង​បង្កើន​តម្លៃ​នេះ​បើ​យោង​តាម​អង្គ​ចងចាំ​រួម​ដែល​ពួកគេ​ចង់​ប្រើ។

កំហុសក្នុងការកំណត់រចនាសម្ព័ន្ធខុសដែលអាចកើតមាន

ប្រសិនបើ SHMMAX មិនត្រូវបានកំណត់រចនាសម្ព័ន្ធត្រឹមត្រូវទេ អ្នកអាចទទួលបានកំហុសនៅពេលព្យាយាមចាប់ផ្តើមក្រុម PostgreSQL ដោយប្រើពាក្យបញ្ជា initdb.

initdb បរាជ័យ
DETAIL: Failed system call was shmget(key=1, size=2072576, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter. 
You can either reduce the request size or reconfigure the kernel with larger SHMMAX. To reduce the request size (currently 2072576 bytes),
reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration. child process exited with exit code 1

ដូចគ្នានេះដែរ អ្នកអាចទទួលបានកំហុសនៅពេលចាប់ផ្តើមម៉ាស៊ីនមេ PostgreSQL ដោយប្រើពាក្យបញ្ជា pg_ctl.

pg_ctl បរាជ័យ
DETAIL: Failed system call was shmget(key=5432001, size=14385152, 03600).

HINT: This error usually means that PostgreSQL's request for a shared memory segment exceeded your kernel's SHMMAX parameter.

You can either reduce the request size or reconfigure the kernel with larger SHMMAX.; To reduce the request size (currently 14385152 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.

If the request size is already small, it's possible that it is less than your kernel's SHMMIN parameter,
in which case raising the request size or reconfiguring SHMMIN is called for.

The PostgreSQL documentation contains more information about shared memory configuration.

ការយល់ដឹងពីភាពខុសគ្នានៃនិយមន័យ

ការកំណត់ប៉ារ៉ាម៉ែត្រ SHMMAX/SHMALL គឺខុសគ្នាបន្តិចបន្តួចនៅលើ Linux និង MacOS X៖

• លីនុច៖ kernel.shmmax, kernel.shmall
• MacOS X៖ kern.sysv.shmmax, kern.sysv.shmall

ក្រុមការងារ អេសស៊ីល អាចត្រូវបានប្រើដើម្បីផ្លាស់ប្តូរតម្លៃជាបណ្តោះអាសន្ន។ ដើម្បីកំណត់តម្លៃថេរ បន្ថែមធាតុទៅ /etc/sysctl.conf. ព័ត៌មានលម្អិតមាននៅខាងក្រោម។

ការផ្លាស់ប្តូរការកំណត់ខឺណែលនៅលើ MacOS X

# Get the value of SHMMAX
sudo sysctl kern.sysv.shmmax
kern.sysv.shmmax: 4096

# Get the value of SHMALL
sudo sysctl kern.sysv.shmall 
kern.sysv.shmall: 4096

# Set the value of SHMMAX
sudo sysctl -w kern.sysv.shmmax=16777216
kern.sysv.shmmax: 4096 -> 16777216

# Set the value of SHMALL 
sudo sysctl -w kern.sysv.shmall=16777216
kern.sysv.shmall: 4096 -> 16777216

ការផ្លាស់ប្តូរប៉ារ៉ាម៉ែត្រខឺណែលនៅលើលីនុច

# Get the value of SHMMAX
sudo sysctl kernel.shmmax
kernel.shmmax: 4096

# Get the value of SHMALL
sudo sysctl kernel.shmall
kernel.shmall: 4096

# Set the value of SHMMAX
sudo sysctl -w kernel.shmmax=16777216
kernel.shmmax: 4096 -> 16777216

# Set the value of SHMALL 
sudo sysctl -w kernel.shmall=16777216
kernel.shmall: 4096 -> 16777216

កុំ​ភ្លេច៖ ដើម្បីធ្វើការផ្លាស់ប្តូរជាអចិន្ត្រៃយ៍ បន្ថែមតម្លៃទាំងនេះទៅ /etc/sysctl.conf

ទំព័រដ៏ធំ

លីនុចប្រើទំព័រអង្គចងចាំ 4 KB តាមលំនាំដើម BSD ប្រើទំព័រអង្គចងចាំ XNUMX KB ។ ទំព័រទំនើបនិងនៅលើ Windows - ទំព័រធំ. ទំព័រគឺជាបំណែកនៃ RAM ដែលត្រូវបានបម្រុងទុកសម្រាប់ដំណើរការមួយ។ ដំណើរការមួយអាចមានច្រើនទំព័រ អាស្រ័យលើតម្រូវការអង្គចងចាំ។ ដំណើរការត្រូវការអង្គចងចាំកាន់តែច្រើន ទំព័រកាន់តែច្រើនត្រូវបានបែងចែក។ OS រក្សាតារាងបែងចែកទំព័រសម្រាប់ដំណើរការ។ ទំហំទំព័រកាន់តែតូច តារាងកាន់តែធំ វាត្រូវការពេលយូរដើម្បីស្វែងរកទំព័រក្នុងតារាងទំព័រនោះ។ ដូច្នេះ ទំព័រធំអនុញ្ញាតឱ្យប្រើអង្គចងចាំច្រើនជាមួយនឹងការកាត់បន្ថយលើស។ ចំនួនមើលទំព័រតិចជាង កំហុសទំព័រតិចជាង ប្រតិបត្តិការអាន/សរសេរលឿនជាងលើបណ្តុំធំជាង។ លទ្ធផលគឺការកែលម្អការអនុវត្ត។

PostgreSQL គាំទ្រតែទំព័រធំនៅលើលីនុចប៉ុណ្ណោះ។ តាមលំនាំដើម លីនុចប្រើទំព័រអង្គចងចាំ 4 KB ដូច្នេះក្នុងករណីដែលមានប្រតិបត្តិការអង្គចងចាំច្រើនពេក ចាំបាច់ត្រូវកំណត់ទំព័រធំជាង។ ការកើនឡើងនៃការអនុវត្តត្រូវបានគេសង្កេតឃើញនៅពេលប្រើទំព័រធំ 2 MB និងរហូតដល់ 1 GB ។ ទំហំទំព័រធំអាចត្រូវបានកំណត់នៅពេលចាប់ផ្ដើម។ អ្នកអាចពិនិត្យមើលប៉ារ៉ាម៉ែត្រទំព័រធំ និងការប្រើប្រាស់របស់វាយ៉ាងងាយស្រួលនៅលើម៉ាស៊ីនលីនុចរបស់អ្នកដោយប្រើពាក្យបញ្ជា ឆ្មា /proc/meminfo | grep - ខ្ញុំធំ.

ទទួលបានព័ត៌មានអំពីទំព័រធំ (លីនុចតែប៉ុណ្ណោះ)

Note: This is only for Linux, for other OS this operation is ignored$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:       0
HugePages_Free:        0
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

ក្នុងឧទាហរណ៍នេះ ទោះបីជាទំហំទំព័រធំត្រូវបានកំណត់ទៅ 2048 (2 MB) ប៉ុន្តែចំនួនទំព័រធំសរុបត្រូវបានកំណត់ទៅ 0។ នេះមានន័យថាទំព័រធំត្រូវបានបិទ។

ស្គ្រីបសម្រាប់កំណត់ចំនួនទំព័រធំ

ស្គ្រីបសាមញ្ញនេះត្រឡប់ចំនួនទំព័រធំដែលត្រូវការ។ ដំណើរការស្គ្រីបនៅលើម៉ាស៊ីនមេលីនុចរបស់អ្នកខណៈពេលដែល PostgreSQL កំពុងដំណើរការ។ ត្រូវប្រាកដថាសម្រាប់បរិស្ថានប្រែប្រួល $PGDATA ថតទិន្នន័យ PostgreSQL ត្រូវបានបញ្ជាក់។

ទទួលបានចំនួនទំព័រធំដែលត្រូវការ

#!/bin/bash
pid=`head -1 $PGDATA/postmaster.pid`
echo "Pid:            $pid"
peak=`grep ^VmPeak /proc/$pid/status | awk '{ print $2 }'`
echo "VmPeak:            $peak kB"
hps=`grep ^Hugepagesize /proc/meminfo | awk '{ print $2 }'`
echo "Hugepagesize:   $hps kB"
hp=$((peak/hps))
echo Set Huge Pages:     $hp

លទ្ធផលស្គ្រីបមើលទៅដូចនេះ៖

លទ្ធផលស្គ្រីប

Pid:            12737
VmPeak:         180932 kB
Hugepagesize:   2048 kB
Set Huge Pages: 88

តម្លៃដែលបានណែនាំសម្រាប់ទំព័រធំគឺ 88 ដូច្នេះអ្នកគួរតែកំណត់វាទៅជា 88។

ការដំឡើងទំព័រធំ

sysctl -w vm.nr_hugepages=88

សូមពិនិត្យមើលទំព័រធំឥឡូវនេះ អ្នកនឹងឃើញថាទំព័រធំមិនត្រូវបានប្រើទេ (HugePages_Free = HugePages_Total)។

ទំព័រធំបានមើលឡើងវិញ (លីនុចតែប៉ុណ្ណោះ)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       88
HugePages_Rsvd:        0
HugePages_Surp:        0
Hugepagesize:       2048 kB

ឥឡូវនេះកំណត់ប៉ារ៉ាម៉ែត្រ huge_pages ទៅ "បើក" នៅក្នុង $PGDATA/postgresql.conf ហើយចាប់ផ្តើមម៉ាស៊ីនមេឡើងវិញ។

ជាថ្មីម្តងទៀត ព័ត៌មានអំពីទំព័រធំ (លីនុចតែប៉ុណ្ណោះ)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       81
HugePages_Rsvd:       64
HugePages_Surp:        0
Hugepagesize:       2048 kB

ឥឡូវ​នេះ អ្នក​អាច​ឃើញ​ថា​ទំព័រ​ធំៗ​តិចតួច​ណាស់​ត្រូវ​បាន​គេ​ប្រើ។ ឥឡូវនេះ ចូរយើងព្យាយាមបន្ថែមទិន្នន័យមួយចំនួនទៅក្នុងមូលដ្ឋានទិន្នន័យ។

ប្រតិបត្តិការមូលដ្ឋានទិន្នន័យមួយចំនួនដើម្បីកែច្នៃទំព័រធំ

postgres=# CREATE TABLE foo(a INTEGER);
CREATE TABLE
postgres=# INSERT INTO foo VALUES(generate_Series(1,10000000));
INSERT 0 10000000

សូមមើលថាតើយើងកំពុងប្រើទំព័រធំជាងមុនឥឡូវនេះឬអត់។

ព័ត៌មានបន្ថែមនៅលើទំព័រធំ (លីនុចតែប៉ុណ្ណោះ)

$ cat /proc/meminfo | grep -i huge
AnonHugePages:         0 kB
ShmemHugePages:        0 kB
HugePages_Total:      88
HugePages_Free:       18
HugePages_Rsvd:        1
HugePages_Surp:        0
Hugepagesize:       2048 kB

ឥឡូវនេះអ្នកអាចមើលឃើញថាភាគច្រើននៃទំព័រធំកំពុងត្រូវបានប្រើប្រាស់។

ចំណាំ៖ តម្លៃប៉ាន់ស្មានសម្រាប់ HugePages ដែលប្រើនៅទីនេះគឺទាបណាស់ ដែលមិនមែនជាតម្លៃធម្មតាសម្រាប់ម៉ាស៊ីនដែលកំពុងដំណើរការបរិស្ថានផលិតផល។ សូមប៉ាន់ប្រមាណចំនួនទំព័រដែលត្រូវការសម្រាប់ប្រព័ន្ធរបស់អ្នក ហើយកំណត់វាទៅតាមការផ្ទុក និងធនធាន។

vm. swappiness

vm. swappiness គឺជាប៉ារ៉ាម៉ែត្រខឺណែលមួយផ្សេងទៀតដែលអាចប៉ះពាល់ដល់ដំណើរការមូលដ្ឋានទិន្នន័យ។ ជម្រើស​នេះ​ត្រូវ​បាន​ប្រើ​ដើម្បី​គ្រប់គ្រង​ឥរិយាបថ​នៃ​ការ​ប្តូរ​ទំព័រ (ប្តូរ​ទំព័រ​ក្នុង និង​ក្រៅ​អង្គចងចាំ) ក្នុង​លីនុច។ តម្លៃមានចាប់ពី 0 ដល់ 100។ វាកំណត់ថាតើចំនួនអង្គចងចាំនឹងត្រូវដាក់ទំព័រ ឬបិទទំព័រ។ សូន្យមានន័យថាគ្មានការផ្លាស់ប្តូរ ហើយ 100 មានន័យថាការដោះដូរដ៏ឈ្លានពាន។

អ្នកអាចទទួលបានដំណើរការល្អដោយកំណត់តម្លៃទាប។

ការកំណត់នេះទៅ 0 នៅលើខឺណែលថ្មីអាចបណ្តាលឱ្យ OOM Killer (ដំណើរការសម្អាតអង្គចងចាំរបស់លីនុច) ដើម្បីសម្លាប់ដំណើរការនេះ។ ដូច្នេះវាមានសុវត្ថិភាពក្នុងការកំណត់វាទៅ 1 ប្រសិនបើអ្នកចង់កាត់បន្ថយការដោះដូរ។ តម្លៃលំនាំដើមនៅក្នុងលីនុចគឺ 60។ តម្លៃខ្ពស់ធ្វើឱ្យ MMU (អង្គភាពគ្រប់គ្រងអង្គចងចាំ) ប្រើទំហំស្វបច្រើនជាង RAM ខណៈដែលតម្លៃទាបរក្សាទិន្នន័យ/កូដកាន់តែច្រើននៅក្នុងអង្គចងចាំ។

តម្លៃទាបគឺជាការភ្នាល់ដ៏ល្អសម្រាប់ដំណើរការប្រសើរឡើងនៅក្នុង PostgreSQL ។

vm.overcommit_memory / vm.overcommit_ratio

កម្មវិធីទទួលបានអង្គចងចាំ ហើយបញ្ចេញវានៅពេលដែលវាលែងត្រូវការ។ ប៉ុន្តែក្នុងករណីខ្លះកម្មវិធីទទួលបានអង្គចងចាំច្រើនពេកហើយមិនបញ្ចេញវាទេ។ នេះអាចបណ្តាលឱ្យឃាតករ OOM ។ នេះគឺជាតម្លៃប៉ារ៉ាម៉ែត្រដែលអាចធ្វើបាន vm.overcommit_memory ជាមួយនឹងការពិពណ៌នាសម្រាប់នីមួយៗ៖

1. Heuristic overcommit (លំនាំដើម); សរីរវិទ្យាផ្អែកលើខឺណែល
2. អនុញ្ញាត​ឱ្យ​លើស​ពី​នេះ​ទៀត​
3. កុំធ្វើឱ្យវាហួសប្រមាណ កុំឱ្យលើសពីសមាមាត្រដែលលើស។

សេចក្តីយោង: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio - ភាគរយនៃ RAM ដែលអាចប្រើបានសម្រាប់ការផ្ទុកលើសទម្ងន់។ តម្លៃ 50% នៅលើប្រព័ន្ធដែលមាន RAM 2 GB អាចបែងចែក RAM រហូតដល់ 3 GB ។

តម្លៃ 2 សម្រាប់ vm.overcommit_memory ផ្តល់នូវដំណើរការប្រសើរជាងមុនសម្រាប់ PostgreSQL ។ តម្លៃនេះបង្កើនការប្រើប្រាស់ RAM របស់ដំណើរការម៉ាស៊ីនមេ ដោយគ្មានហានិភ័យធ្ងន់ធ្ងរណាមួយដែលនឹងត្រូវបានសម្លាប់ដោយដំណើរការឃាតករ OOM ។ កម្មវិធីនឹងអាចដំណើរការឡើងវិញបាន ប៉ុន្តែមានតែនៅក្នុងដែនកំណត់នៃការរត់ហួសកម្រិតប៉ុណ្ណោះ ដែលកាត់បន្ថយហានិភ័យនៃឃាតករ OOM ដែលសម្លាប់ដំណើរការនេះ។ ដូច្នេះតម្លៃនៃ 2 ផ្តល់នូវដំណើរការប្រសើរជាងតម្លៃលំនាំដើមនៃ 0។ ទោះជាយ៉ាងណាក៏ដោយ ភាពជឿជាក់អាចត្រូវបានកែលម្អដោយធានាថាអង្គចងចាំក្រៅជួរមិនត្រូវបានផ្ទុកលើសទម្ងន់នោះទេ។ នេះលុបបំបាត់ហានិភ័យនៃដំណើរការដែលត្រូវបានសម្លាប់ដោយឃាតករ OOM ។

នៅលើប្រព័ន្ធដែលមិនមានការផ្លាស់ប្តូរ បញ្ហាជាមួយ vm.overcommit_memory ស្មើនឹង 2 អាចកើតឡើង។

https://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT

vm.dirty_background_ratio / vm.dirty_background_bytes

vm.dirty_background_ratio គឺ​ជា​ភាគរយ​នៃ​អង្គ​ចងចាំ​ដែល​ពោរពេញ​ដោយ​ទំព័រ​កខ្វក់​ដែល​ត្រូវ​សរសេរ​ទៅ​ថាស។ ការហូរទៅថាសកើតឡើងនៅផ្ទៃខាងក្រោយ។ តម្លៃនៃប៉ារ៉ាម៉ែត្រនេះមានចាប់ពី 0 ដល់ 100; ទោះយ៉ាងណាក៏ដោយ តម្លៃក្រោម 5 អាចនឹងគ្មានប្រសិទ្ធភាព ហើយខឺណែលខ្លះមិនគាំទ្រវាទេ។ 10 គឺជាលំនាំដើមនៅលើប្រព័ន្ធលីនុចភាគច្រើន។ អ្នកអាចកែលម្អការអនុវត្តសម្រាប់ប្រតិបត្តិការដែលពឹងផ្អែកខ្លាំងលើការសរសេរដោយកត្តាតូចជាង ដែលនឹងមានន័យថាលីនុចនឹងលុបទំព័រកខ្វក់នៅក្នុងផ្ទៃខាងក្រោយ។

អ្នកត្រូវកំណត់តម្លៃ vm.dirty_background_bytes អាស្រ័យលើល្បឿននៃដ្រាយរបស់អ្នក។

មិនមានតម្លៃ "ល្អ" សម្រាប់ប៉ារ៉ាម៉ែត្រទាំងពីរនេះទេ ព្រោះទាំងពីរគឺអាស្រ័យលើផ្នែករឹង។ ទោះយ៉ាងណាក៏ដោយ ការកំណត់ vm.dirty_background_ratio ទៅ 5 និង vm.dirty_background_bytes ដល់ 25% នៃល្បឿនឌីសធ្វើអោយប្រសើរឡើងនូវដំណើរការទៅ ~25% ក្នុងករណីភាគច្រើន។

vm.dirty_ratio/dirty_bytes

វាដូចគ្នានឹង vm.dirty_background_ratio/dirty_background_bytesលើកលែងតែការកំណត់ឡើងវិញត្រូវបានអនុវត្តនៅក្នុងវគ្គកម្មករ ដោយរារាំងកម្មវិធី។ ដូច្នេះ vm.dirty_ratio គួរតែខ្ពស់ជាង vm.dirty_background_ratio. នេះធានាថាដំណើរការផ្ទៃខាងក្រោយចាប់ផ្តើមមុននេះ ដើម្បីជៀសវាងការទប់ស្កាត់កម្មវិធីតាមដែលអាចធ្វើទៅបាន។ អ្នកអាចកែតម្រូវភាពខុសគ្នារវាងសមាមាត្រទាំងពីរនេះ អាស្រ័យលើការផ្ទុក I/O របស់ថាស។

លទ្ធផល

អ្នកអាចកែប្រែការកំណត់ផ្សេងទៀតដើម្បីកែលម្អដំណើរការ ប៉ុន្តែការកែលម្អនឹងមានតិចតួច ហើយអ្នកនឹងមិនឃើញអត្ថប្រយោជន៍ច្រើនទេ។ យើងត្រូវតែចងចាំថា មិនមែនគ្រប់ជម្រើសទាំងអស់អនុវត្តចំពោះកម្មវិធីគ្រប់ប្រភេទនោះទេ។ កម្មវិធីមួយចំនួនដំណើរការប្រសើរជាងនៅពេលយើងកែតម្រូវការកំណត់មួយចំនួន ហើយកម្មវិធីខ្លះមិនដំណើរការ។ អ្នកត្រូវតែស្វែងរកសមតុល្យដ៏ត្រឹមត្រូវរវាងការកំណត់រចនាសម្ព័ន្ធទាំងនេះសម្រាប់បន្ទុកការងារដែលរំពឹងទុក និងប្រភេទកម្មវិធីរបស់អ្នក ហើយអ្នកក៏ត្រូវពិចារណាអំពីឥរិយាបថរបស់ប្រព័ន្ធប្រតិបត្តិការផងដែរនៅពេលលៃតម្រូវ។ ការ​កំណត់​រចនាសម្ព័ន្ធ​ប៉ារ៉ាម៉ែត្រ​ខឺណែល​មិន​ងាយស្រួល​ដូច​ការ​កំណត់​ប៉ារ៉ាម៉ែត្រ​មូលដ្ឋាន​ទិន្នន័យ​ទេ វា​ពិបាក​ជាង​ក្នុង​ការ​ណែនាំ។

ប្រភព: www.habr.com