بہترین PostgreSQL کارکردگی درست طریقے سے بیان کردہ آپریٹنگ سسٹم کے پیرامیٹرز پر منحصر ہے۔ ناقص کنفیگر شدہ OS کرنل سیٹنگز کے نتیجے میں ڈیٹا بیس سرور کی کارکردگی خراب ہو سکتی ہے۔ لہذا، یہ ضروری ہے کہ یہ ترتیبات ڈیٹا بیس سرور اور اس کے کام کے بوجھ کے مطابق ترتیب دی جائیں۔ اس پوسٹ میں، ہم کچھ اہم لینکس کرنل پیرامیٹرز پر تبادلہ خیال کریں گے جو ڈیٹا بیس سرور کی کارکردگی کو متاثر کر سکتے ہیں اور انہیں کیسے ترتیب دیا جائے۔
SHMMAX / SHMALL
SHMMAX ایک کرنل پیرامیٹر ہے جو کسی ایک مشترکہ میموری سیگمنٹ کے زیادہ سے زیادہ سائز کا تعین کرنے کے لیے استعمال ہوتا ہے جسے لینکس کا عمل مختص کر سکتا ہے۔ ورژن 9.2 سے پہلے، PostgreSQL سسٹم V (SysV) کا استعمال کرتا ہے، جس کے لیے SHMMAX سیٹنگ کی ضرورت ہوتی ہے۔ 9.2 کے بعد، PostgreSQL POSIX مشترکہ میموری میں تبدیل ہو گیا۔ لہذا اب سسٹم 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) = 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 استعمال کرتا ہے۔ سسٹم 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 پیرامیٹرز کی وضاحت لینکس اور 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 میموری صفحات استعمال کرتا ہے۔ سپر صفحات، اور ونڈوز پر - بڑے صفحات. ایک صفحہ RAM کا ایک ٹکڑا ہے جو کسی عمل کے لیے مختص کیا جاتا ہے۔ میموری کی ضروریات کے لحاظ سے ایک عمل میں متعدد صفحات ہوسکتے ہیں۔ ایک عمل کو جتنی زیادہ میموری کی ضرورت ہوتی ہے، اتنے ہی زیادہ صفحات مختص ہوتے ہیں۔ OS عمل کے لیے صفحہ مختص کرنے کی میز کو برقرار رکھتا ہے۔ صفحہ کا سائز جتنا چھوٹا ہوگا، ٹیبل اتنا ہی بڑا ہوگا، اس صفحہ کی میز میں صفحہ تلاش کرنے میں اتنا ہی زیادہ وقت لگتا ہے۔ لہذا بڑے صفحات کم اوور ہیڈ کے ساتھ بڑی مقدار میں میموری استعمال کرنے کی اجازت دیتے ہیں۔ کم پیج ویوز، کم پیج فالٹس، بڑے بفرز پر تیزی سے پڑھنے/لکھنے کے آپریشنز۔ نتیجہ بہتر کارکردگی ہے.
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 چل رہا ہو۔ یقینی بنائیں کہ ماحولیاتی متغیر کے لئے $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 پیرامیٹر کو "آن" پر سیٹ کریں اور سرور کو دوبارہ شروع کریں۔
ایک بار پھر، بڑے صفحات کے بارے میں معلومات (صرف لینکس)
$ 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 (Linux کی میموری کی صفائی کا عمل) اس عمل کو ختم کر سکتا ہے۔ لہذا اگر آپ تبادلہ کو کم سے کم کرنا چاہتے ہیں تو اسے 1 پر سیٹ کرنا محفوظ ہے۔ لینکس میں ڈیفالٹ ویلیو 60 ہے۔ زیادہ ویلیو MMU (میموری مینجمنٹ یونٹ) کو RAM کے مقابلے میں زیادہ سویپ اسپیس استعمال کرنے کا سبب بنتی ہے، جب کہ کم ویلیو میموری میں زیادہ ڈیٹا/کوڈ رکھتی ہے۔
PostgreSQL میں بہتر کارکردگی کے لیے کم قیمت ایک اچھی شرط ہے۔
vm.overcommit_memory / vm.overcommit_ratio
ایپلی کیشنز میموری حاصل کرتی ہیں اور اسے چھوڑ دیتی ہیں جب اس کی مزید ضرورت نہیں ہوتی ہے۔ لیکن کچھ معاملات میں، ایپلی کیشن بہت زیادہ میموری حاصل کرتی ہے اور اسے جاری نہیں کرتی ہے۔ یہ OOM قاتل کا سبب بن سکتا ہے۔ پیرامیٹر کی ممکنہ قدریں یہ ہیں۔ vm.overcommit_memory ہر ایک کی وضاحت کے ساتھ:
- Heuristic overcommit (پہلے سے طے شدہ)؛ دانا پر مبنی ہورسٹک
- بہرحال اوور کمیٹ کی اجازت دیں۔
- اسے زیادہ نہ کریں، اوور کمیٹ ریشو سے تجاوز نہ کریں۔
حوالہ:
vm.overcommit_ratio — اوورلوڈ کے لیے دستیاب RAM کا فیصد۔ 50 GB RAM والے سسٹم پر 2% کی قدر 3 GB تک RAM مختص کر سکتی ہے۔
vm.overcommit_memory کے لیے 2 کی قدر PostgreSQL کے لیے بہتر کارکردگی فراہم کرتی ہے۔ یہ قدر OOM قاتل عمل سے مارے جانے کے کسی خاص خطرے کے بغیر سرور کے RAM کے استعمال کو زیادہ سے زیادہ کرتی ہے۔ ایپلیکیشن دوبارہ لوڈ کرنے کے قابل ہو گی، لیکن صرف اووررن کی حدود میں، جس سے OOM قاتل کے عمل کو ختم کرنے کا خطرہ کم ہو جاتا ہے۔ لہذا، 2 کی قدر 0 کی پہلے سے طے شدہ قدر سے بہتر کارکردگی فراہم کرتی ہے۔ تاہم، اس بات کو یقینی بنا کر کہ رینج سے باہر کی میموری اوورلوڈ نہ ہو، اعتبار کو بہتر بنایا جا سکتا ہے۔ یہ ایک OOM قاتل کے ذریعہ عمل کے مارے جانے کے خطرے کو ختم کرتا ہے۔
تبدیل کیے بغیر سسٹمز پر، vm.overcommit_memory 2 کے برابر مسئلہ ہو سکتا ہے۔
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 لوڈ کے لحاظ سے ان دو تناسب کے درمیان فرق کو ایڈجسٹ کر سکتے ہیں۔
کل
کارکردگی کو بہتر بنانے کے لیے آپ دوسری سیٹنگز کو موافقت دے سکتے ہیں، لیکن بہتری کم سے کم ہوگی اور آپ کو زیادہ فائدہ نظر نہیں آئے گا۔ ہمیں یاد رکھنا چاہیے کہ تمام اختیارات تمام قسم کی ایپلی کیشنز پر لاگو نہیں ہوتے ہیں۔ جب ہم کچھ ترتیبات کو ایڈجسٹ کرتے ہیں تو کچھ ایپس بہتر کام کرتی ہیں، اور کچھ نہیں کرتی ہیں۔ آپ کو اپنے متوقع کام کے بوجھ اور ایپلیکیشن کی قسم کے لیے ان ترتیبات کو ترتیب دینے کے درمیان صحیح توازن تلاش کرنا چاہیے، اور آپ کو ٹیوننگ کرتے وقت OS کے رویے پر بھی غور کرنا چاہیے۔ کرنل پیرامیٹرز کو ترتیب دینا اتنا آسان نہیں جتنا ڈیٹا بیس کے پیرامیٹرز کو ترتیب دینا؛ سفارشات کرنا زیادہ مشکل ہے۔
ماخذ: www.habr.com