Optimal PostgreSQL ڪارڪردگي صحيح طور تي بيان ڪيل آپريٽنگ سسٽم جي پيٽرولن تي منحصر آهي. خراب ترتيب ڏنل OS ڪنييل سيٽنگون خراب ڊيٽابيس سرور ڪارڪردگي جي نتيجي ۾ ٿي سگھي ٿي. تنهن ڪري، اهو ضروري آهي ته اهي سيٽنگون ڊيٽابيس سرور ۽ ان جي ڪم لوڊ جي مطابق ترتيب ڏنل آهن. هن پوسٽ ۾، اسان بحث ڪنداسين ڪجهه اهم لينڪس ڪنييل پيٽرولر جيڪي متاثر ڪري سگهن ٿا ڊيٽابيس سرور جي ڪارڪردگي ۽ انهن کي ڪيئن ترتيب ڏيڻ.
SHMMAX / SHMALL
SHMMAX هڪ ڪنيل پيٽرولر آهي استعمال ڪيو ويندو آهي وڌ ۾ وڌ سائيز کي طئي ڪرڻ لاءِ هڪ واحد شيئر ڪيل ياداشت واري حصي جي جيڪا هڪ لينڪس پروسيس مختص ڪري سگهي ٿي. نسخو 9.2 کان اڳ، PostgreSQL استعمال ڪيو سسٽم V (SysV)، جنهن کي SHMMAX سيٽنگ جي ضرورت آهي. 9.2 کان پوء، PostgreSQL کي تبديل ڪيو ويو POSIX شيئر ميموري. تنهن ڪري هاڻي سسٽم V شيئر ميموري جا ٿورا بائيٽ گهربل آهن.
نسخو 9.3 کان اڳ، SHMMAX سڀ کان اهم ڪنييل پيٽرولر هو. SHMMAX قدر بائيٽ ۾ بيان ڪيو ويو آهي.
ساڳي طرح SHMALL هڪ ٻيو ڪنيل پيٽرولر آهي جيڪو طئي ڪرڻ لاء استعمال ڪيو ويندو آهي
شيئر ڪيل ميموري صفحن جو سسٽم-وائڊ حجم. موجوده SHMMAX، SHMALL، يا SHMMIN قدر ڏسڻ لاء، حڪم استعمال ڪريو ipcs.
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) = 1SHM * تفصيل - 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 استعمال ڪري ٿو سسٽم وي آئي پي سي گڏيل ياداشت کي مختص ڪرڻ لاء. هي پيٽرول سڀ کان اهم ڪنيل پيٽرولر مان هڪ آهي. جڏهن به توهان هيٺ ڏنل غلطي پيغام وصول ڪندا آهيو، ان جو مطلب اهو آهي ته توهان وٽ 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 پيٽرولر جي وضاحت لينڪس ۽ MacOS X تي ٿورڙي مختلف آهي:
- لينڪس: kernel.shmmax، kernel.shmall
- MacOS X: kern.sysv.shmmax، kern.sysv.shmall
ٽيم sysctl عارضي طور تي قدر کي تبديل ڪرڻ لاءِ استعمال ڪري سگھجي ٿو. مستقل قدر قائم ڪرڻ لاءِ، داخلا شامل ڪريو /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 ميموري صفحا استعمال ڪري ٿو. سپر صفحا، ۽ ونڊوز تي - وڏا صفحا. هڪ صفحو رام جو هڪ ٽڪرو آهي جيڪو هڪ عمل لاءِ مختص ڪيو ويو آهي. ھڪڙي عمل ۾ ڪيترائي صفحا ٿي سگھن ٿا ياداشت جي ضرورتن جي لحاظ کان. وڌيڪ ياداشت جي هڪ پروسيس جي ضرورت هوندي آهي، وڌيڪ صفحا مختص ڪيا ويندا آهن. او ايس پروسيس لاءِ صفحي جي مختص ٽيبل کي برقرار رکي ٿو. پيج جي سائيز جيتري ننڍي هوندي، ٽيبل جيتري وڏي هوندي، اوترو ئي ان پيج ٽيبل ۾ هڪ صفحو ڳولڻ ۾ وڌيڪ وقت لڳندو. تنهن ڪري وڏا صفحا اجازت ڏين ٿا ميموري جي وڏي مقدار کي استعمال ڪرڻ جي گھٽتائي سان. گهٽ صفحو ڏيک، گهٽ صفحو غلطيون، تيز پڙهڻ/لکڻ جا عمل وڏن بفرن تي. نتيجو بهتر ڪارڪردگي آهي.
PostgreSQL صرف لينڪس تي وڏن صفحن کي سپورٽ ڪري ٿو. ڊفالٽ طور، لينڪس 4 KB ميموري صفحا استعمال ڪري ٿو، تنهنڪري ڪيسن ۾ جتي تمام گهڻيون ميموري آپريشن آهن، اهو ضروري آهي ته وڏن صفحن کي ترتيب ڏيو. 2 MB ۽ 1 GB تائين وڏا صفحا استعمال ڪرڻ دوران ڪارڪردگي حاصلات جو مشاهدو ڪيو ويو آهي. وڏي صفحي جي سائيز بوٽ وقت تي مقرر ڪري سگهجي ٿو. توهان آساني سان چيڪ ڪري سگهو ٿا وڏي صفحي جي پيٽرولن ۽ انهن جو استعمال توهان جي لينڪس مشين تي ڪمانڊ استعمال ڪندي cat/proc/meminfo | grep - i وڏو.
وڏن صفحن بابت ڄاڻ حاصل ڪرڻ (صرف لينڪس)
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 ھلندو آھي. پڪ ڪريو ته ماحولياتي variable لاء $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ھاڻي $PGDATA/postgresql.conf ۾ large_pages پيٽرولر کي "on" تي سيٽ ڪريو ۽ سرور کي ٻيهر شروع ڪريو.
هڪ ڀيرو ٻيهر، وڏن صفحن بابت ڄاڻ (صرف لينڪس)
$ 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 هڪ ٻيو ڪنيل پيٽرولر آهي جيڪو ڊيٽابيس جي ڪارڪردگي کي متاثر ڪري سگهي ٿو. هي اختيار لينڪس ۾ swappiness جي رويي کي ڪنٽرول ڪرڻ لاءِ استعمال ڪيو ويندو آهي (صفحن کي ميموري ۾ ۽ ٻاهر تبديل ڪرڻ) لينڪس ۾. قيمت جي حد 0 کان 100 تائين آھي. اھو طئي ڪري ٿو ته ڪيتري ميموري کي پيج ڪيو ويندو يا پيج آئوٽ ڪيو ويندو. زيرو جو مطلب آھي ڪو بدلو نه آھي ۽ 100 جو مطلب آھي جارحاڻي بدلي.
توھان حاصل ڪري سگھوٿا سٺي ڪارڪردگي گھٽ قيمتون ترتيب ڏيڻ سان.
ھن کي نون ڪنلن تي 0 ڪرڻ سان OOM Killer (لينڪس جي ميموري صاف ڪرڻ وارو عمل) عمل کي ختم ڪري سگھي ٿو. تنهن ڪري ان کي 1 تي سيٽ ڪرڻ محفوظ آهي جيڪڏهن توهان مٽائڻ کي گهٽائڻ چاهيو ٿا. لينڪس ۾ ڊفالٽ ويليو 60 آهي. هڪ وڌيڪ قيمت MMU (ميموري مئنيجمينٽ يونٽ) کي رام جي ڀيٽ ۾ وڌيڪ سويپ اسپيس استعمال ڪرڻ جو سبب بڻائي ٿي، جڏهن ته گهٽ قيمت ميموري ۾ وڌيڪ ڊيٽا/ڪوڊ رکي ٿي.
PostgreSQL ۾ بهتر ڪارڪردگيءَ لاءِ گهٽ قيمت هڪ سٺي شرط آهي.
vm.overcommit_memory / vm.overcommit_ratio
ايپليڪيشنون ميموري حاصل ڪن ٿيون ۽ ان کي ڇڏي ڏيو جڏهن ان کي وڌيڪ ضرورت ناهي. پر ڪجهه حالتن ۾، ايپليڪيشن تمام گهڻي ياداشت حاصل ڪري ٿي ۽ ان کي ڇڏي نه ٿو. اهو ٿي سگهي ٿو هڪ OOM قاتل. هتي ممڪن پيراميٽر قدر آهن vm.overcommit_memory هر هڪ جي وضاحت سان:
- Heuristic overcommit (ڊفالٽ)؛ kernel تي ٻڌل heuristic
- ڪنهن به صورت ۾ overcommit جي اجازت ڏيو
- ان کي وڌيڪ نه ڪريو، اوورڪميٽ تناسب کان وڌيڪ نه ڪريو.
حوالو
vm.overcommit_ratio - اوورلوڊ لاءِ موجود رام جو سيڪڙو. 50 GB ريم سان سسٽم تي 2٪ جي قيمت 3 GB ريم تائين مختص ڪري سگھي ٿي.
vm.overcommit_memory لاءِ 2 جو قدر PostgreSQL لاءِ بهتر ڪارڪردگي مهيا ڪري ٿو. هي قدر سرور جي پروسيس جي رام جي استعمال کي وڌائي ٿو بغير ڪنهن خاص خطري جي OOM قاتل عمل طرفان قتل ٿيڻ جي. ايپليڪيشن ٻيهر لوڊ ڪرڻ جي قابل ٿي ويندي، پر صرف اووررن جي حدن جي اندر، جيڪو عمل کي مارڻ واري OOM قاتل جي خطري کي گھٽائي ٿو. تنهن ڪري، 2 جي قيمت 0 جي ڊفالٽ قيمت کان بهتر ڪارڪردگي ڏئي ٿي. جڏهن ته، رينج کان ٻاهر جي ياداشت کي اوورلوڊ نه ڪرڻ کي يقيني بڻائي اعتماد کي بهتر بڻائي سگهجي ٿو. اهو عمل جي خطري کي ختم ڪري ٿو جيڪو OOM قاتل طرفان قتل ڪيو وڃي ٿو.
سسٽم تي بغير تبديل ڪرڻ جي، هڪ مسئلو vm.overcommit_memory سان 2 جي برابر ٿي سگھي ٿي.
vm.dirty_background_ratio / vm.dirty_background_bytes
vm.dirty_background_ratio ميموري جو سيڪڙو گندي صفحن سان ڀريل آهي جنهن کي ڊسڪ تي لکڻ جي ضرورت آهي. ڊسڪ کي فلش پس منظر ۾ ٿئي ٿي. ھن پيٽرولر جي قيمت 0 کان 100 تائين آھي؛ جڏهن ته، 5 کان هيٺ هڪ قدر غير اثرائتو ٿي سگهي ٿو ۽ ڪجهه ڪنيل ان کي سپورٽ نٿا ڪن. 10 اڪثر لينڪس سسٽم تي ڊفالٽ آهي. توھان ڪارڪردگي کي بھتر ڪري سگھوٿا لکڻ جي گھڻائي واري عملن لاءِ ھڪ نن factorي عنصر سان، جنھن جو مطلب ھوندو لينڪس پس منظر ۾ گندا صفحا فلش ڪندو.
توهان کي قيمت مقرر ڪرڻ جي ضرورت آهي 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 لوڊ جي لحاظ سان.
نتيجو
توهان ڪارڪردگي کي بهتر ڪرڻ لاء ٻين سيٽنگن کي ٽائيڪ ڪري سگهو ٿا، پر بهتري گهٽ ۾ گهٽ هوندي ۽ توهان گهڻو فائدو نه ڏسندا. اسان کي ياد رکڻ گهرجي ته سڀئي اختيارن سڀني قسمن جي ايپليڪيشنن تي لاڳو ٿين ٿيون. ڪجهه ائپس بهتر ڪم ڪن ٿيون جڏهن اسان ڪجهه سيٽنگون ترتيب ڏيون ٿا، ۽ ڪجهه نه ٿيون. توھان کي توھان جي متوقع ڪم لوڊ ۽ ايپليڪيشن جي قسم لاءِ انھن سيٽنگن کي ترتيب ڏيڻ جي وچ ۾ صحيح توازن ڳولڻ گھرجي، ۽ توھان کي لازمي طور تي OS رويي تي غور ڪرڻ گھرجي جڏھن ٽيوننگ. ڪنيل پيرا ميٽرز کي ترتيب ڏيڻ ايترو آسان ناهي جيترو ڊيٽابيس پيٽرولر کي ترتيب ڏيڻ؛ سفارشون ڪرڻ وڌيڪ ڏکيو آهي.
جو ذريعو: www.habr.com