পোস্টগ্রেএসকিউএল অপ্টিমাইজ করতে লিনাক্স কার্নেল বিকল্পগুলি টিউন করা হচ্ছে

সর্বোত্তম PostgreSQL কর্মক্ষমতা সঠিকভাবে সংজ্ঞায়িত অপারেটিং সিস্টেম প্যারামিটারের উপর নির্ভর করে। খারাপভাবে কনফিগার করা OS কার্নেল সেটিংসের ফলে ডাটাবেস সার্ভারের কর্মক্ষমতা খারাপ হতে পারে। অতএব, এই সেটিংস ডাটাবেস সার্ভার এবং এর কাজের চাপ অনুযায়ী কনফিগার করা আবশ্যক। এই পোস্টে, আমরা কিছু গুরুত্বপূর্ণ লিনাক্স কার্নেল প্যারামিটার নিয়ে আলোচনা করব যা ডাটাবেস সার্ভারের কর্মক্ষমতাকে প্রভাবিত করতে পারে এবং কীভাবে সেগুলি কনফিগার করতে হয়।

SHMMAX / SHMALL

SHMMAX একটি কার্নেল পরামিতি একটি একক ভাগ করা মেমরি অংশের সর্বাধিক আকার নির্ধারণ করতে ব্যবহৃত হয় যা একটি Linux প্রক্রিয়া বরাদ্দ করতে পারে। সংস্করণ 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) = 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 ব্যবহার করে সিস্টেম ভি আইপিসি ভাগ করা মেমরি বরাদ্দ করতে। এই পরামিতিটি সবচেয়ে গুরুত্বপূর্ণ কার্নেল পরামিতিগুলির মধ্যে একটি। যখনই আপনি নিম্নলিখিত ত্রুটির বার্তাগুলি পান, এর মানে হল যে আপনার কাছে 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

টীম 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 এমবি এবং 1 গিগাবাইট পর্যন্ত বড় পৃষ্ঠাগুলি ব্যবহার করার সময় কর্মক্ষমতা বৃদ্ধি পরিলক্ষিত হয়। বড় পৃষ্ঠার আকার বুট সময় সেট করা যেতে পারে. আপনি কমান্ড ব্যবহার করে আপনার লিনাক্স মেশিনে বড় পৃষ্ঠার প্যারামিটার এবং তাদের ব্যবহার সহজেই পরীক্ষা করতে পারেন cat /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

এখন $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 কিলার (লিনাক্সের মেমরি পরিষ্কার করার প্রক্রিয়া) প্রক্রিয়াটি বন্ধ করে দিতে পারে। তাই এটি 1 এ সেট করা নিরাপদ যদি আপনি অদলবদল কম করতে চান। লিনাক্সে ডিফল্ট মান হল 60। একটি উচ্চ মান MMU (মেমরি ম্যানেজমেন্ট ইউনিট) RAM এর চেয়ে বেশি সোয়াপ স্পেস ব্যবহার করে, যখন একটি কম মান মেমরিতে আরও ডেটা/কোড রাখে।

PostgreSQL-এ উন্নত কর্মক্ষমতার জন্য নিম্ন মান একটি ভালো বাজি।

vm.overcommit_memory / vm.overcommit_ratio

অ্যাপ্লিকেশনগুলি মেমরি অর্জন করে এবং যখন এটির আর প্রয়োজন হয় না তখন এটি ছেড়ে দেয়। কিন্তু কিছু ক্ষেত্রে, অ্যাপ্লিকেশনটি খুব বেশি মেমরি পায় এবং এটি প্রকাশ করে না। এটি একটি OOM হত্যাকারীর কারণ হতে পারে। এখানে সম্ভাব্য পরামিতি মান আছে vm.overcommit_memory প্রতিটির জন্য একটি বিবরণ সহ:

1. হিউরিস্টিক ওভারকমিট (ডিফল্ট); কার্নেল-ভিত্তিক হিউরিস্টিক
2. যাইহোক overcommit অনুমতি দিন
3. এটি অতিরিক্ত করবেন না, ওভারকমিট অনুপাত অতিক্রম করবেন না।

লিঙ্ক: https://www.kernel.org/doc/Documentation/vm/overcommit-accounting

vm.overcommit_ratio — ওভারলোডের জন্য উপলব্ধ RAM এর শতাংশ। 50 GB RAM সহ একটি সিস্টেমে 2% এর মান 3 GB পর্যন্ত RAM বরাদ্দ করতে পারে।

vm.overcommit_memory-এর জন্য 2-এর মান PostgreSQL-এর জন্য আরও ভাল কর্মক্ষমতা প্রদান করে। এই মানটি OOM কিলার প্রক্রিয়ার দ্বারা নিহত হওয়ার কোনো উল্লেখযোগ্য ঝুঁকি ছাড়াই সার্ভার প্রক্রিয়ার RAM ব্যবহারকে সর্বাধিক করে তোলে। অ্যাপ্লিকেশনটি পুনরায় লোড করতে সক্ষম হবে, তবে শুধুমাত্র ওভাররানের সীমার মধ্যে, যা একটি OOM হত্যাকারী প্রক্রিয়াটিকে হত্যা করার ঝুঁকি হ্রাস করে। তাই, 2-এর মান 0-এর ডিফল্ট মানের থেকে ভালো কর্মক্ষমতা দেয়। যাইহোক, রেঞ্জের বাইরের মেমরি যাতে ওভারলোড না হয় তা নিশ্চিত করে নির্ভরযোগ্যতা উন্নত করা যেতে পারে। এটি একটি OOM হত্যাকারীর দ্বারা মারা যাওয়ার প্রক্রিয়ার ঝুঁকি দূর করে।

অদলবদল ছাড়া সিস্টেমে, 2 এর সমান vm.overcommit_memory এর সাথে একটি সমস্যা হতে পারে।

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 লোডের উপর নির্ভর করে এই দুটি অনুপাতের মধ্যে পার্থক্য সামঞ্জস্য করতে পারেন।

ফলাফল

কর্মক্ষমতা উন্নত করতে আপনি অন্যান্য সেটিংস পরিবর্তন করতে পারেন, তবে উন্নতিগুলি ন্যূনতম হবে এবং আপনি খুব বেশি সুবিধা দেখতে পাবেন না। আমাদের মনে রাখতে হবে যে সমস্ত বিকল্প সব ধরনের অ্যাপ্লিকেশনের জন্য প্রযোজ্য নয়। কিছু অ্যাপ আরও ভাল কাজ করে যখন আমরা কিছু সেটিংস সামঞ্জস্য করি এবং কিছু করে না। আপনার প্রত্যাশিত কাজের চাপ এবং অ্যাপ্লিকেশন প্রকারের জন্য এই সেটিংস কনফিগার করার মধ্যে আপনাকে অবশ্যই সঠিক ভারসাম্য খুঁজে পেতে হবে এবং টিউন করার সময় আপনাকে অবশ্যই OS আচরণ বিবেচনা করতে হবে। কার্নেল প্যারামিটার কনফিগার করা ডাটাবেস প্যারামিটার কনফিগার করার মতো সহজ নয়; সুপারিশ করা আরও কঠিন।

উত্স: www.habr.com