VPN வழியாக psql நேர அளவீடு: நெட்வொர்க் காத்திருப்பை வினவலின் வேலையிலிருந்து பிரித்தல்

உங்கள் அறிக்கை தரவுத்தள ஹோஸ்ட்டில் சுமார் ஒரு வினாடியிலும் VPN வழியாக நான்கிலும் முடிகிறது, மேலும் psql அச்சிடும் எண் நேரடியாக தரவுத்தளத்தை நோக்கிக் காட்டுகிறது. அந்த எண் கிளையண்ட் பக்கத்தின் நிறுத்துக்கடிகாரம், சர்வரின் அளவீடு அல்ல. அது கூற்று வெளியே செல்லும் பாதை, பதிலுக்கான காத்திருப்பு மற்றும் திரும்பி வரும் வரிகளை உள்ளடக்குகிறது. இந்த மூன்றையும் பிரிப்பதே எந்தப் பக்கத்தைச் சரிசெய்ய வேண்டும் என்பதை அறியும் ஒரே வழி.

psql நேரங்காட்டி உண்மையில் எதை அளக்கிறது

\timing on கிளையண்ட் கூற்றை சாக்கெட்டில் எழுதுவதற்குச் சற்று முன்பு நிறுத்துக்கடிகாரத்தைத் தொடங்கி, அந்த முடிவின் கடைசி வரி படிக்கப்பட்டதும் நிறுத்துகிறது. சர்வரின் சொந்த செயலாக்கம் அந்தச் சாளரத்திற்குள் எங்கோ உள்ளது, பாக்கெட்டுகள் சுரங்கப்பாதையில் செலவிடும் ஒவ்வொரு மில்லிவினாடியும் அப்படியே. வெளியீட்டில் எதுவும் அவற்றைப் பிரிக்கவில்லை. EXPLAIN ஒரு எண்ணையும் அச்சிடுகிறது, ஆனால் அதை சர்வர் உருவாக்குகிறது, கிளையண்டின் காத்திருப்பை விலக்குகிறது. இரண்டு எண்கள், இரண்டு வெவ்வேறு கேள்விகள்.

ஒரு அமர்வைத் தொடங்கி, நேர அளவீட்டை இயக்கத்தில் வைத்து, உங்களுக்கு முக்கியமான கூற்றை அதனுள் இருந்து இயக்கவும். அமர்வை மீண்டும் பயன்படுத்துவது இணைப்புச் செலவை முதல் அளவீட்டிற்கு வெளியே வைத்திருக்கும்.

psql "host=db.internal port=5432 dbname=appdb user=app" \
  -c "\timing on" \
  -c "select count(*) from orders where created_at > now() - interval '1 day';"

எண் இன்னும் முடிவின் பரிமாற்றத்தை உள்ளடக்கியுள்ளது, அதுவே இங்கு உங்களுக்குத் தேவை. புதிய அழைப்பு சேர்க்கும் இணைப்பு மற்றும் அங்கீகாரப் பரிமாற்றத்தை அது இனி உள்ளடக்காது.

ஒரு கூற்றை மூன்று பாதைகளில் ஒப்பிடுங்கள்

அதே கூற்றை Unix சாக்கெட், LAN முகவரி மற்றும் VPN ஹோஸ்ட் பெயர் வழியாக இயக்கி மூன்றையும் ஒப்பிடுங்கள். கடைசி மட்டுமே மெதுவாக இருந்தால், வினவல் மாறி அல்ல.

ஒவ்வொரு அழைப்பும் முதலில் இணைந்து பின்னரே கூற்றை அளக்கிறது, எனவே இணைப்புச் செலவு எண்ணுக்கு வெளியேயும் பரிமாற்றம் உள்ளேயும் இருக்கும். WHERE உட்கூறு, வரி எண்ணிக்கை மற்றும் கிளையண்ட் இயந்திரத்தை ஒரே மாதிரி வைத்திருங்கள், இல்லையெனில் நீங்கள் பாதைகளை அல்ல, பணிச்சுமைகளை ஒப்பிடுகிறீர்கள்.

psql -h /var/run/postgresql -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h 10.40.0.12 -U app -d appdb -c "\timing on" -c "select count(*) from orders;"
psql -h db.vpn.internal -U app -d appdb -c "\timing on" -c "select count(*) from orders;"

LAN இல் வேறுபாடு பொதுவாக புறக்கணிக்கக்கூடிய அளவுக்குச் சிறியது; VPN வழியாக பல நேரங்களில் அப்படி இல்லை. மூன்று முடிவுகளை வரிசைப்படுத்தினால் எந்தக் காத்திருப்பைத் தாக்க வேண்டும் என்பது தெரியும்.

மெதுவான உள்ளூர் சாக்கெட் என்பது சர்வர் வேலை அல்லது திட்டமிடல். மெதுவான LAN முடிவு என்பது வினவல் அல்லது அது நகர்த்தும் அளவு. VPN முடிவு மட்டும் மெதுவாக இருப்பது என்பது பாதையில் தாமதம், MTU அல்லது கிடைக்கும் அலைவரிசை, மேலும் எந்த குறியீட்டு மாற்றமும் அதைச் சரிசெய்யாது.

சர்வரின் சொந்த செயலாக்க நேரத்தை எடுங்கள்

சர்வர் எவ்வளவு நேரம் செலவிட்டது என்பதைத் தெரிவிக்க முடியும், கிளையண்டின் எண்ணுடன் ஒப்பிட வேண்டியது அந்த எண்ணே. ANALYZE உடன் EXPLAIN கூற்றை இயக்கி திட்டத்திற்குள் திட்டமிடல் மற்றும் செயலாக்க நேரத்தை அச்சிடுகிறது, BUFFERS சூடான ஓட்டத்தை குளிர்ந்த ஓட்டத்திலிருந்து பிரிக்கும் தற்காலிக சேமிப்பு நடத்தையைச் சேர்க்கிறது. எழுதும் எண்ணம் இல்லாவிட்டால் அதை எழுத்துக் கூற்றுகளுக்குத் திருப்ப வேண்டாம். படிக்க மட்டும் உள்ள நகலில் தொடங்குவதற்கு மிகப் பாதுகாப்பான இடம் அதுவே, மேலும் psql குறிப்பு நேரங்காட்டியின் கிளையண்ட் பக்க எல்லையை ஆவணப்படுத்துகிறது.

பயன்பாடு ஏற்கனவே இயக்கும் கூற்றுகளுக்கு, pg_stat_statements எதையும் மீண்டும் இயக்காமல் சர்வர் பக்க செயலாக்கத்தைத் தொகுக்கிறது. வரிகள் இயல்பாக்கப்பட்ட வினவலுக்கு, எனவே ஒரு பதிவு பல அழைப்பு இடங்களை உள்ளடக்கலாம்.

select calls, round(mean_exec_time::numeric, 2) as mean_ms, rows
from pg_stat_statements
order by mean_exec_time desc
limit 5;

நிரல் பெயர்கள் வெளியீட்டின் படி மாறும்: PostgreSQL 13 மற்றும் அதற்குப் பின் mean_exec_time வெளிப்படுத்துகின்றன, பழைய பதிப்புகள் அதை mean_time என்கின்றன, எனவே சரிபார்க்கவும் \d pg_stat_statements மூலம், அந்த வினவல் பிழை கொடுத்தால். இந்த மதிப்புகள் திட்டமிடலை விலக்குகின்றன, உங்கள் கிளையண்ட் வரையிலான பயணத்தையும் விலக்குகின்றன. அந்த விலக்கே அவற்றை ஒப்பீட்டிற்குப் பயனுள்ளதாக்குகிறது.

சென்று வரும் பயணங்களை எண்ணுங்கள், மில்லிவினாடிகள் மட்டும் அல்ல

இருநூறு சிறிய சார்பு கூற்றுகளால் கட்டப்பட்ட அறிக்கை பாதை சேர்க்கும் எந்தத் தாமதத்தையும் இருநூறால் பெருக்குகிறது. ஒரு மில்லியன் வரிகளைத் திருப்பித் தரும் ஒரு கூற்று அந்தத் தாமதத்தை ஒரு முறை செலுத்தி பின்னர் நீண்ட நேரம் அலைவரிசையைச் செலுத்துகிறது. இரண்டும் கிளையண்ட் நேரங்காட்டியில் ஒரே மாதிரி தெரிகின்றன, இரண்டுக்கும் எதிர் திருத்தங்கள் தேவை.

கூற்றுகளின் எண்ணிக்கையை மதிப்பிடாமல் அளவிடுங்கள். மொத்தத்தைப் படித்து, அறிக்கையை ஒரு முறை இயக்கி, பின்னர் மீண்டும் படித்துக் கழிக்கவும்.

select sum(calls) as calls from pg_stat_statements;
-- run the report here
select sum(calls) as calls from pg_stat_statements;

டெல்டா பெரியதாகவும் ஒவ்வொரு கூற்றும் சர்வரில் மலிவாகவும் இருந்தால், தொகுத்தல் பலன் தரும் திருத்தம். சார்பு வினவல்களை இணைக்கவும், ஒரு தொகுப்பு அடிப்படையிலான கூற்றைப் பயன்படுத்தவும், அல்லது கர்சரில் இருந்து சுழற்சியை இயக்கவும். ஊடாடும் psql இல், \set FETCH_COUNT 1000 பெரிய முடிவு தொகுதிகளாக வர அனுமதித்து பரிமாற்றம் மற்றும் கிளையண்ட் நினைவகத்தின் நடத்தையை மாற்றுகிறது. இது சர்வர் வேலையைக் குறைக்காது, எனவே மெதுவான வினவலைக் காப்பாற்றாது.

சுரங்கப்பாதையை மறுசெலுத்தம் மற்றும் MTU நிறுத்தங்களுக்குச் சரிபார்க்கவும்

சிறிய கூற்றுகள் வேகமாகவும் பெரிய முடிவுகள் பாதி வழியில் நிற்கும் போதும், வினவல் பொதுவாக சரியாக இருக்கும், பாதை அல்ல. அடிப்படை இணைப்பை விட MTU குறைவாக உள்ள சுரங்கப்பாதை, தடுக்கப்பட்ட ICMP உடன் சேர்ந்து அதே வடிவத்தை உருவாக்குகிறது: முதல் பாக்கெட்டுகள் வருகின்றன, பெரியவை மறைந்துவிடுகின்றன, பரிமாற்றம் மீண்டும் முயற்சிக்கும் வரை தொங்குகிறது. கிளையண்ட் பக்க மறுசெலுத்த எண்ணிகள் அதைக் காட்டுகின்றன.

வேண்டுமென்றே மெதுவான பரிமாற்றம் நடக்கும்போது சாக்கெட் மற்றும் கர்னல் எண்ணிகளைக் கவனியுங்கள். மறுசெலுத்தத் தொகைகள் கூட்டுத்தொகை, எனவே ஒரு மாதிரியைப் படிப்பதற்குப் பதிலாக முன்னும் பின்னும் குறித்துக்கொள்ளுங்கள்.

ss -tin dst 10.40.0.12
netstat -s | grep -iE "retransmit|segments retransmitted"
ping -M do -s 1400 -c 3 10.40.0.12

பரிமாற்றத்தின் போது உயரும் மறுசெலுத்தங்கள், 1400 பைட்டில் வெற்றி பெற்று 1472 இல் தோல்வியடையும் ping உடன், தரவுத்தளப் பிரச்சினை அல்ல MTU பிரச்சினையைச் சுட்டுகின்றன. சுரங்கப்பாதை இடைமுகத்தின் MTU ஐக் குறைப்பது அல்லது நுழைவாயிலில் MSS ஐ இறுக்குவது வழக்கமான திருத்தம், அதே மூன்று கட்டளைகள் பின்னர் அதை உறுதிப்படுத்துகின்றன. பரிமாற்றம் இன்னும் மெதுவாக இருக்கும்போது மறுசெலுத்தங்கள் சமதளமாக இருந்தால், இழப்பை அல்ல, சுரங்கப்பாதைக்கு அனுமதிக்கப்பட்ட அலைவரிசையைப் பாருங்கள்.

ஒரு சிறிய வரிசை அடுத்த மெதுவான அறிக்கையை உள்ளடக்குகிறது: ஒரு கூற்றை உள்ளூர், LAN மற்றும் VPN வழியாக ஒப்பிடுங்கள்; EXPLAIN அல்லது pg_stat_statements இல் இருந்து சர்வர் செயலாக்கத்தைப் படியுங்கள்; ஒரு முறை இயக்குவதற்கு முன்னும் பின்னும் அழைப்புகளை எண்ணுங்கள்; பெரிய முடிவு நகரும் போது மறுசெலுத்தங்களைக் கவனியுங்கள். ஒவ்வொரு படியும் பாதையின் ஒரு பக்கத்தை விலக்குகிறது. எதுவும் எந்தக் கூறை மறுதொடக்கம் செய்ய வேண்டும் என்று ஊகிக்கக் கேட்கவில்லை.