PostgreSQL મોનિટરિંગની મૂળભૂત બાબતો. એલેક્સી લેસોવ્સ્કી

હું સૂચન કરું છું કે તમે ડેટા એગ્રેટ “ફન્ડામેન્ટલ્સ ઑફ પોસ્ટગ્રેએસક્યુએલ મોનિટરિંગ”માંથી એલેક્સી લેસોવસ્કીના અહેવાલની ટ્રાન્સક્રિપ્ટ વાંચો.

આ અહેવાલમાં, એલેક્સી લેસોવ્સ્કી પોસ્ટ-ગ્રેસના આંકડાઓના મુખ્ય મુદ્દાઓ વિશે વાત કરશે, તેનો અર્થ શું છે અને તેઓ શા માટે મોનિટરિંગમાં હાજર હોવા જોઈએ; મોનિટરિંગમાં કયા ગ્રાફ્સ હોવા જોઈએ, તેને કેવી રીતે ઉમેરવું અને તેનું અર્થઘટન કેવી રીતે કરવું તે વિશે. આ રિપોર્ટ ડેટાબેઝ એડમિનિસ્ટ્રેટર્સ, સિસ્ટમ એડમિનિસ્ટ્રેટર્સ અને ડેવલપર્સ માટે ઉપયોગી થશે કે જેઓ Postgres મુશ્કેલીનિવારણમાં રસ ધરાવે છે.

મારું નામ એલેક્સી લેસોવ્સ્કી છે, હું ડેટા એગ્રેટ કંપનીનું પ્રતિનિધિત્વ કરું છું.

મારા વિશે થોડાક શબ્દો. મેં સિસ્ટમ એડમિનિસ્ટ્રેટર તરીકે લાંબા સમય પહેલા શરૂઆત કરી હતી.

મેં તમામ પ્રકારની વિવિધ Linux સિસ્ટમ્સનું સંચાલન કર્યું, Linux ને લગતી વિવિધ વસ્તુઓ પર કામ કર્યું, એટલે કે વર્ચ્યુઅલાઈઝેશન, મોનિટરિંગ, પ્રોક્સી સાથે કામ કર્યું, વગેરે. પરંતુ અમુક સમયે મેં ડેટાબેઝ, PostgreSQL સાથે વધુ કામ કરવાનું શરૂ કર્યું. હું તેને ખરેખર ગમ્યો. અને અમુક સમયે મેં મારા મોટાભાગના કામકાજના સમય PostgreSQL પર કામ કરવાનું શરૂ કર્યું. અને તેથી ધીમે ધીમે હું PostgreSQL DBA બન્યો.

અને મારી સમગ્ર કારકિર્દી દરમિયાન, મને હંમેશા આંકડા, દેખરેખ અને ટેલિમેટ્રીના વિષયોમાં રસ રહ્યો છે. અને જ્યારે હું સિસ્ટમ એડમિનિસ્ટ્રેટર હતો, ત્યારે મેં Zabbix સાથે ખૂબ નજીકથી કામ કર્યું. અને મેં સ્ક્રિપ્ટનો એક નાનો સેટ લખ્યો zabbix-એક્સ્ટેન્શન્સ. તેઓ તેમના સમયમાં ખૂબ જ લોકપ્રિય હતા. અને ત્યાં ફક્ત લિનક્સ જ નહીં, પરંતુ વિવિધ ઘટકો પણ ખૂબ જ અલગ મહત્વપૂર્ણ વસ્તુઓનું નિરીક્ષણ કરવું શક્ય હતું.

હવે હું PostgreSQL પર કામ કરી રહ્યો છું. હું પહેલેથી જ બીજી વસ્તુ લખી રહ્યો છું જે તમને PostgreSQL આંકડાઓ સાથે કામ કરવાની મંજૂરી આપે છે. તે કહેવાય છે pgCenter (હાબ્રે પરનો લેખ - ચેતા અને તણાવ વિના પોસ્ટ-ગ્રેસના આંકડા).

થોડી પરિચય નોંધ. અમારા ગ્રાહકો, અમારા ગ્રાહકોની કઈ પરિસ્થિતિઓ છે? ડેટાબેઝને લગતો કોઈ પ્રકારનો અકસ્માત છે. અને જ્યારે ડેટાબેઝ પહેલેથી જ પુનઃસ્થાપિત કરવામાં આવે છે, ત્યારે વિભાગના વડા અથવા વિકાસના વડા આવે છે અને કહે છે: "મિત્રો, આપણે ડેટાબેઝનું નિરીક્ષણ કરવાની જરૂર છે, કારણ કે કંઈક ખરાબ થયું છે અને આપણે ભવિષ્યમાં આવું થતું અટકાવવાની જરૂર છે." અને અહીં મોનિટરિંગ સિસ્ટમ પસંદ કરવાની અથવા હાલની મોનિટરિંગ સિસ્ટમને અનુકૂલિત કરવાની રસપ્રદ પ્રક્રિયા શરૂ થાય છે જેથી કરીને તમે તમારા ડેટાબેઝ - PostgreSQL, MySQL અથવા અન્ય કેટલાકને મોનિટર કરી શકો. અને સાથીદારો સૂચવવાનું શરૂ કરે છે: “મેં સાંભળ્યું છે કે આવા અને આવા ડેટાબેઝ છે. ચાલો તેનો ઉપયોગ કરીએ." સાથીદારો એકબીજા સાથે દલીલ કરવાનું શરૂ કરે છે. અને અંતે તે તારણ આપે છે કે આપણે અમુક પ્રકારનો ડેટાબેઝ પસંદ કરીએ છીએ, પરંતુ PostgreSQL મોનિટરિંગ તેના બદલે ખરાબ રીતે રજૂ કરવામાં આવ્યું છે અને આપણે હંમેશા કંઈક ઉમેરવું પડશે. GitHub માંથી કેટલીક રીપોઝીટરીઝ લો, તેમને ક્લોન કરો, સ્ક્રિપ્ટ્સને અનુકૂલિત કરો અને કોઈક રીતે તેમને કસ્ટમાઇઝ કરો. અને અંતે તે અમુક પ્રકારના મેન્યુઅલ વર્ક તરીકે સમાપ્ત થાય છે.

તેથી, આ ચર્ચામાં હું તમને માત્ર PostgreSQL માટે જ નહીં, પણ ડેટાબેઝ માટે પણ મોનિટરિંગ કેવી રીતે પસંદ કરવું તે અંગે થોડું જ્ઞાન આપવાનો પ્રયત્ન કરીશ. અને તમને તે જ્ઞાન આપે છે જે તમને તમારા મોનિટરિંગને પૂર્ણ કરવા માટે પરવાનગી આપે છે જેથી કરીને તેનાથી થોડો ફાયદો થાય, જેથી તમે તમારા ડેટાબેઝને લાભ સાથે મોનિટર કરી શકો, જેથી આવનારી કોઈપણ કટોકટીની પરિસ્થિતિઓને તાત્કાલિક અટકાવી શકાય.

અને આ રિપોર્ટમાં જે વિચારો હશે તે કોઈપણ ડેટાબેઝમાં સીધા જ અનુકૂલિત થઈ શકે છે, પછી તે DBMS અથવા noSQL હોય. તેથી, ત્યાં માત્ર PostgreSQL જ નથી, પરંતુ PostgreSQL માં આ કેવી રીતે કરવું તેની ઘણી વાનગીઓ હશે. પ્રશ્નોના ઉદાહરણો હશે, પોસ્ટગ્રેએસક્યુએલ પાસે મોનિટરિંગ માટે હોય તેવા એન્ટિટીના ઉદાહરણો હશે. અને જો તમારા DBMS પાસે સમાન વસ્તુઓ છે જે તમને તેમને મોનિટરિંગમાં મૂકવાની મંજૂરી આપે છે, તો તમે તેમને અનુકૂલિત પણ કરી શકો છો, તેમને ઉમેરી શકો છો અને તે સારું રહેશે.

હું રિપોર્ટમાં નહીં હોઈશ
મેટ્રિક્સ કેવી રીતે પહોંચાડવા અને સ્ટોર કરવા તે વિશે વાત કરો. હું ડેટાને પોસ્ટ-પ્રોસેસ કરવા અને તેને વપરાશકર્તા સમક્ષ રજૂ કરવા વિશે કંઈ કહીશ નહીં. અને હું ચેતવણી વિશે કંઈ કહીશ નહીં.
પરંતુ જેમ જેમ વાર્તા આગળ વધશે, હું હાલના મોનિટરિંગના જુદા જુદા સ્ક્રીનશૉટ્સ બતાવીશ અને કોઈક રીતે તેમની ટીકા કરીશ. પરંતુ તેમ છતાં, હું બ્રાન્ડ્સને નામ ન આપવાનો પ્રયાસ કરીશ જેથી કરીને આ ઉત્પાદનો માટે જાહેરાતો અથવા વિરોધી જાહેરાત ન બને. તેથી, બધા સંયોગો રેન્ડમ છે અને તમારી કલ્પના પર છોડી દેવામાં આવે છે.

પ્રથમ, ચાલો સમજીએ કે મોનીટરીંગ શું છે. મોનિટરિંગ એ ખૂબ જ મહત્વપૂર્ણ બાબત છે. દરેક વ્યક્તિ આ સમજે છે. પરંતુ તે જ સમયે, દેખરેખ વ્યવસાય ઉત્પાદન સાથે સંબંધિત નથી અને કંપનીના નફાને સીધી અસર કરતું નથી, તેથી મોનિટરિંગને હંમેશા શેષ ધોરણે સમય આપવામાં આવે છે. જો અમારી પાસે સમય છે, તો અમે મોનિટરિંગમાં રોકાયેલા છીએ, જો સમય નથી, તો ઠીક છે, અમે તેને બેકલોગમાં મૂકીશું અને કોઈ દિવસ અમે આ કાર્યો પર પાછા આવીશું.

તેથી, અમારી પ્રેક્ટિસમાંથી, જ્યારે અમે ક્લાયન્ટ્સ પાસે આવીએ છીએ, ત્યારે મોનિટરિંગ ઘણીવાર અધૂરું હોય છે અને તેમાં એવી કોઈ રસપ્રદ બાબતો હોતી નથી જે ડેટાબેઝ સાથે વધુ સારું કામ કરવામાં અમને મદદ કરે. અને તેથી મોનિટરિંગ હંમેશા સમાપ્ત કરવાની જરૂર છે.

ડેટાબેઝ એ એવી જટિલ વસ્તુઓ છે જેના પર પણ દેખરેખ રાખવાની જરૂર છે, કારણ કે ડેટાબેઝ એ માહિતીનો ભંડાર છે. અને કંપની માટે માહિતી ખૂબ જ મહત્વપૂર્ણ છે; તે કોઈપણ રીતે ગુમાવી શકાતી નથી. પરંતુ તે જ સમયે, ડેટાબેઝ સોફ્ટવેરના ખૂબ જટિલ ટુકડાઓ છે. તેઓ મોટી સંખ્યામાં ઘટકો ધરાવે છે. અને આમાંના ઘણા ઘટકોને મોનિટર કરવાની જરૂર છે.

જો આપણે પોસ્ટગ્રેએસક્યુએલ વિશે ખાસ વાત કરી રહ્યા છીએ, તો તે એક યોજનાના સ્વરૂપમાં રજૂ કરી શકાય છે જેમાં મોટી સંખ્યામાં ઘટકોનો સમાવેશ થાય છે. આ ઘટકો એકબીજા સાથે ક્રિયાપ્રતિક્રિયા કરે છે. અને તે જ સમયે, PostgreSQL પાસે કહેવાતા આંકડા કલેક્ટર સબસિસ્ટમ છે, જે તમને આ સબસિસ્ટમના સંચાલન વિશે આંકડા એકત્રિત કરવાની અને એડમિનિસ્ટ્રેટર અથવા વપરાશકર્તાને અમુક પ્રકારનું ઈન્ટરફેસ પ્રદાન કરવા દે છે જેથી તે આ આંકડા જોઈ શકે.

આ આંકડા કાર્યો અને દૃશ્યોના ચોક્કસ સમૂહના સ્વરૂપમાં રજૂ કરવામાં આવે છે. તેમને કોષ્ટકો પણ કહી શકાય. એટલે કે, નિયમિત psql ક્લાયંટનો ઉપયોગ કરીને, તમે ડેટાબેઝ સાથે કનેક્ટ કરી શકો છો, આ કાર્યો અને દૃશ્યો પર પસંદગી કરી શકો છો અને PostgreSQL સબસિસ્ટમના સંચાલન વિશે કેટલાક ચોક્કસ નંબરો મેળવી શકો છો.

તમે આ નંબરોને તમારી મનપસંદ મોનિટરિંગ સિસ્ટમમાં ઉમેરી શકો છો, ગ્રાફ દોરી શકો છો, ફંક્શન ઉમેરી શકો છો અને લાંબા ગાળે એનાલિટિક્સ મેળવી શકો છો.

પરંતુ આ અહેવાલમાં હું આ તમામ કાર્યોને સંપૂર્ણપણે આવરી લઈશ નહીં, કારણ કે તેમાં આખો દિવસ લાગી શકે છે. હું શાબ્દિક રીતે બે, ત્રણ અથવા ચાર વસ્તુઓને સંબોધિત કરીશ અને તમને કહીશ કે તેઓ કેવી રીતે મોનિટરિંગને બહેતર બનાવવામાં મદદ કરે છે.

અને જો આપણે ડેટાબેઝ મોનીટરીંગ વિશે વાત કરીએ, તો પછી શું મોનીટર કરવાની જરૂર છે? સૌ પ્રથમ, અમારે ઉપલબ્ધતા પર દેખરેખ રાખવાની જરૂર છે, કારણ કે ડેટાબેઝ એ એવી સેવા છે જે ગ્રાહકોને ડેટાની ઍક્સેસ પ્રદાન કરે છે અને અમારે ઉપલબ્ધતા પર દેખરેખ રાખવાની જરૂર છે, અને તેની કેટલીક ગુણાત્મક અને માત્રાત્મક લાક્ષણિકતાઓ પણ પ્રદાન કરવાની જરૂર છે.

અમારે અમારા ડેટાબેઝ સાથે કનેક્ટ થતા ક્લાયન્ટ્સ પર પણ નજર રાખવાની જરૂર છે, કારણ કે તેઓ સામાન્ય ક્લાયન્ટ અને હાનિકારક ક્લાયન્ટ બંને હોઈ શકે છે જે ડેટાબેઝને નુકસાન પહોંચાડી શકે છે. તેમની પર નજર રાખવાની અને તેમની પ્રવૃત્તિઓ પર નજર રાખવાની પણ જરૂર છે.

જ્યારે ક્લાયન્ટ્સ ડેટાબેઝ સાથે કનેક્ટ થાય છે, ત્યારે તે સ્પષ્ટ છે કે તેઓ અમારા ડેટા સાથે કામ કરવાનું શરૂ કરે છે, તેથી અમારે મોનિટર કરવાની જરૂર છે કે ક્લાયન્ટ્સ ડેટા સાથે કેવી રીતે કાર્ય કરે છે: કયા કોષ્ટકો સાથે, અને ઓછા અંશે, કયા ઇન્ડેક્સ સાથે. એટલે કે, અમારે અમારા ગ્રાહકો દ્વારા બનાવેલ વર્કલોડનું મૂલ્યાંકન કરવાની જરૂર છે.

પરંતુ વર્કલોડમાં, અલબત્ત, વિનંતીઓનો સમાવેશ થાય છે. એપ્લિકેશનો ડેટાબેઝ સાથે જોડાય છે, ક્વેરીઝનો ઉપયોગ કરીને ડેટાને ઍક્સેસ કરે છે, તેથી ડેટાબેઝમાં આપણી પાસે કઈ ક્વેરી છે તેનું મૂલ્યાંકન કરવું, તેમની પર્યાપ્તતાનું નિરીક્ષણ કરવું, તે કુટિલ રીતે લખાયેલું નથી, કે કેટલાક વિકલ્પોને ફરીથી લખવા અને બનાવવાની જરૂર છે જેથી તેઓ ઝડપથી કાર્ય કરે. અને વધુ સારી કામગીરી સાથે.

અને અમે ડેટાબેઝ વિશે વાત કરી રહ્યા હોવાથી, ડેટાબેઝ હંમેશા પૃષ્ઠભૂમિ પ્રક્રિયાઓ છે. પૃષ્ઠભૂમિ પ્રક્રિયાઓ ડેટાબેઝની કામગીરીને સારા સ્તરે જાળવવામાં મદદ કરે છે, તેથી તેઓને તેમના સંચાલન માટે ચોક્કસ સંસાધનોની જરૂર પડે છે. અને તે જ સમયે, તેઓ ક્લાયંટ વિનંતી સંસાધનો સાથે ઓવરલેપ કરી શકે છે, તેથી લોભી પૃષ્ઠભૂમિ પ્રક્રિયાઓ ક્લાયંટ વિનંતીઓના પ્રદર્શનને સીધી અસર કરી શકે છે. તેથી, તેઓને પણ મોનિટર અને ટ્રૅક કરવાની જરૂર છે જેથી પૃષ્ઠભૂમિ પ્રક્રિયાઓના સંદર્ભમાં કોઈ વિકૃતિઓ ન હોય.

અને ડેટાબેઝ મોનિટરિંગના સંદર્ભમાં આ બધું સિસ્ટમ મેટ્રિકમાં રહે છે. પરંતુ આપણું મોટાભાગનું ઇન્ફ્રાસ્ટ્રક્ચર વાદળો તરફ આગળ વધી રહ્યું છે તે ધ્યાનમાં લેતા, વ્યક્તિગત હોસ્ટની સિસ્ટમ મેટ્રિક્સ હંમેશા પૃષ્ઠભૂમિમાં ઝાંખા પડી જાય છે. પરંતુ ડેટાબેસેસમાં તેઓ હજુ પણ સંબંધિત છે અને, અલબત્ત, સિસ્ટમ મેટ્રિક્સનું નિરીક્ષણ કરવું પણ જરૂરી છે.

સિસ્ટમ મેટ્રિક્સ સાથે બધું વધુ કે ઓછું સારું છે, તમામ આધુનિક મોનિટરિંગ સિસ્ટમ્સ પહેલેથી જ આ મેટ્રિક્સને સમર્થન આપે છે, પરંતુ સામાન્ય રીતે, કેટલાક ઘટકો હજુ પણ પૂરતા નથી અને કેટલીક વસ્તુઓ ઉમેરવાની જરૂર છે. હું તેમના પર પણ સ્પર્શ કરીશ, તેમના વિશે ઘણી સ્લાઇડ્સ હશે.

યોજનાનો પ્રથમ મુદ્દો સુલભતા છે. સુલભતા શું છે? મારી સમજમાં ઉપલબ્ધતા એ સેવા કનેક્શન માટે આધારની ક્ષમતા છે, એટલે કે બેઝ વધારવામાં આવે છે, તે, સેવા તરીકે, ગ્રાહકો પાસેથી કનેક્શન સ્વીકારે છે. અને આ સુલભતાનું મૂલ્યાંકન ચોક્કસ લાક્ષણિકતાઓ દ્વારા કરી શકાય છે. ડેશબોર્ડ્સ પર આ લાક્ષણિકતાઓ પ્રદર્શિત કરવી ખૂબ જ અનુકૂળ છે.

દરેક વ્યક્તિ જાણે છે કે ડેશબોર્ડ શું છે. આ તે છે જ્યારે તમે સ્ક્રીન પર એક નજર નાખો કે જેના પર જરૂરી માહિતીનો સારાંશ આપવામાં આવે છે. અને તમે તરત જ નક્કી કરી શકો છો કે ડેટાબેઝમાં કોઈ સમસ્યા છે કે નહીં.
તદનુસાર, ડેટાબેઝની ઉપલબ્ધતા અને અન્ય મુખ્ય લાક્ષણિકતાઓ હંમેશા ડેશબોર્ડ્સ પર પ્રદર્શિત થવી જોઈએ જેથી આ માહિતી તમારા હાથમાં હોય અને હંમેશા તમારા માટે ઉપલબ્ધ હોય. કેટલીક વધારાની વિગતો કે જે પહેલાથી જ ઘટનાઓની તપાસમાં મદદ કરે છે, જ્યારે કેટલીક કટોકટીની પરિસ્થિતિઓની તપાસ કરવામાં આવે છે, ત્યારે તેને પહેલાથી જ ગૌણ ડેશબોર્ડ્સ પર મૂકવાની જરૂર છે, અથવા ડ્રિલડાઉન લિંક્સમાં છુપાવવાની જરૂર છે જે તૃતીય-પક્ષ મોનિટરિંગ સિસ્ટમ્સ તરફ દોરી જાય છે.

એક જાણીતી મોનિટરિંગ સિસ્ટમનું ઉદાહરણ. આ એક ખૂબ જ શાનદાર મોનિટરિંગ સિસ્ટમ છે. તેણી ઘણો ડેટા એકત્રિત કરે છે, પરંતુ મારા દૃષ્ટિકોણથી, તેણી પાસે ડેશબોર્ડ્સનો વિચિત્ર ખ્યાલ છે. "ડેશબોર્ડ બનાવો" ની લિંક છે. પરંતુ જ્યારે તમે ડેશબોર્ડ બનાવો છો, ત્યારે તમે બે કૉલમની સૂચિ બનાવો છો, આલેખની સૂચિ બનાવો છો. અને જ્યારે તમારે કંઈક જોવાની જરૂર હોય, ત્યારે તમે માઉસથી ક્લિક કરવાનું શરૂ કરો છો, સ્ક્રોલ કરો છો, ઇચ્છિત ચાર્ટ શોધી શકો છો. અને આમાં સમય લાગે છે, એટલે કે ત્યાં કોઈ ડેશબોર્ડ નથી. ત્યાં ફક્ત ચાર્ટની સૂચિ છે.

તમારે આ ડેશબોર્ડ્સમાં શું ઉમેરવું જોઈએ? તમે પ્રતિભાવ સમય જેવી લાક્ષણિકતા સાથે પ્રારંભ કરી શકો છો. PostgreSQL માં pg_stat_statements વ્યુ છે. તે ડિફૉલ્ટ રૂપે અક્ષમ છે, પરંતુ તે એક મહત્વપૂર્ણ સિસ્ટમ દૃશ્યો છે જે હંમેશા સક્ષમ અને ઉપયોગમાં લેવા જોઈએ. તે ડેટાબેઝમાં એક્ઝિક્યુટ કરવામાં આવેલ તમામ ચાલી રહેલી ક્વેરી વિશેની માહિતી સંગ્રહિત કરે છે.

તદનુસાર, અમે એ હકીકતથી શરૂ કરી શકીએ છીએ કે અમે બધી વિનંતીઓનો કુલ અમલ સમય લઈ શકીએ છીએ અને ઉપરોક્ત ક્ષેત્રોનો ઉપયોગ કરીને વિનંતીઓની સંખ્યા દ્વારા તેને વિભાજીત કરી શકીએ છીએ. પરંતુ આ હોસ્પિટલમાં સરેરાશ તાપમાન છે. અમે અન્ય ક્ષેત્રોથી શરૂ કરી શકીએ છીએ - ન્યૂનતમ ક્વેરી એક્ઝેક્યુશન સમય, મહત્તમ અને મધ્ય. અને આપણે પર્સન્ટાઈલ્સ પણ બનાવી શકીએ છીએ; PostgreSQL આ માટે અનુરૂપ કાર્યો ધરાવે છે. અને અમે કેટલાક નંબરો મેળવી શકીએ છીએ જે પહેલાથી જ પૂર્ણ થયેલી વિનંતીઓ માટે અમારા ડેટાબેઝના પ્રતિભાવ સમયને લાક્ષણિકતા આપે છે, એટલે કે અમે નકલી વિનંતી 'સિલેક્ટ 1' ને એક્ઝિક્યુટ કરતા નથી અને પ્રતિસાદનો સમય જોતા નથી, પરંતુ અમે પહેલાથી જ પૂર્ણ થયેલી વિનંતીઓ માટે પ્રતિભાવ સમયનું વિશ્લેષણ કરીએ છીએ અને ડ્રો કરીએ છીએ. કાં તો એક અલગ આકૃતિ, અથવા અમે તેના આધારે ગ્રાફ બનાવીએ છીએ.

સિસ્ટમ દ્વારા હાલમાં જનરેટ કરવામાં આવેલી ભૂલોની સંખ્યાનું નિરીક્ષણ કરવું પણ મહત્વપૂર્ણ છે. અને આ માટે તમે pg_stat_database વ્યુનો ઉપયોગ કરી શકો છો. અમે xact_rollback ક્ષેત્ર પર ધ્યાન કેન્દ્રિત કરીએ છીએ. આ ક્ષેત્ર ડેટાબેઝમાં થતા રોલબેકની સંખ્યા જ બતાવે છે, પણ ભૂલોની સંખ્યાને પણ ધ્યાનમાં લે છે. સાપેક્ષ રીતે કહીએ તો, અમે અમારા ડેશબોર્ડમાં આ આંકડો પ્રદર્શિત કરી શકીએ છીએ અને જોઈ શકીએ છીએ કે અમારી પાસે હાલમાં કેટલી ભૂલો છે. જો ત્યાં ઘણી બધી ભૂલો હોય, તો લોગમાં જોવાનું અને તે કયા પ્રકારની ભૂલો છે અને તે શા માટે થાય છે તે જોવાનું આ એક સારું કારણ છે, અને પછી રોકાણ કરો અને તેને હલ કરો.

તમે ટેકોમીટર જેવી વસ્તુ ઉમેરી શકો છો. આ પ્રતિ સેકન્ડ વ્યવહારોની સંખ્યા અને પ્રતિ સેકન્ડ વિનંતીઓની સંખ્યા છે. સાપેક્ષ રીતે કહીએ તો, તમે તમારા ડેટાબેઝના વર્તમાન પ્રદર્શન તરીકે આ નંબરોનો ઉપયોગ કરી શકો છો અને અવલોકન કરી શકો છો કે શું વિનંતીઓમાં શિખરો છે, વ્યવહારોમાં શિખરો છે અથવા, તેનાથી વિપરીત, ડેટાબેઝ અન્ડરલોડ થયેલ છે કે કેમ કે કેટલાક બેકએન્ડ નિષ્ફળ ગયા છે. હંમેશા આ આંકડો જોવો અને યાદ રાખવું અગત્યનું છે કે અમારા પ્રોજેક્ટ માટે આ પ્રકારનું પ્રદર્શન સામાન્ય છે, પરંતુ ઉપર અને નીચેનાં મૂલ્યો પહેલેથી જ અમુક પ્રકારની સમસ્યારૂપ અને અગમ્ય છે, જેનો અર્થ છે કે આપણે આ સંખ્યાઓ શા માટે છે તે જોવાની જરૂર છે. ખૂબ ઊંચા.

વ્યવહારોની સંખ્યાનો અંદાજ કાઢવા માટે, અમે ફરીથી pg_stat_database વ્યુનો સંદર્ભ લઈ શકીએ છીએ. અમે કમિટ્સની સંખ્યા અને રોલબેકની સંખ્યા ઉમેરી શકીએ છીએ અને પ્રતિ સેકન્ડ વ્યવહારોની સંખ્યા મેળવી શકીએ છીએ.

શું દરેક વ્યક્તિ સમજે છે કે એક વ્યવહારમાં ઘણી વિનંતીઓ ફિટ થઈ શકે છે? તેથી TPS અને QPS થોડા અલગ છે.

પ્રતિ સેકન્ડ વિનંતીઓની સંખ્યા pg_stat_statements પરથી મેળવી શકાય છે અને ખાલી બધી પૂર્ણ કરેલી વિનંતીઓના સરવાળાની ગણતરી કરો. તે સ્પષ્ટ છે કે આપણે વર્તમાન મૂલ્યની અગાઉના મૂલ્ય સાથે તુલના કરીએ છીએ, તેને બાદ કરીએ છીએ, ડેલ્ટા મેળવીએ છીએ અને જથ્થો મેળવીએ છીએ.

જો ઇચ્છિત હોય તો તમે વધારાના મેટ્રિક્સ ઉમેરી શકો છો, જે અમારા ડેટાબેઝની ઉપલબ્ધતાનું મૂલ્યાંકન કરવામાં પણ મદદ કરે છે અને મોનિટર કરવામાં મદદ કરે છે કે ત્યાં કોઈ ડાઉનટાઇમ છે કે કેમ.

આ મેટ્રિક્સમાંથી એક અપટાઇમ છે. પરંતુ PostgreSQL માં અપટાઇમ થોડો મુશ્કેલ છે. હું તમને શા માટે કહીશ. જ્યારે PostgreSQL શરૂ થાય છે, અપટાઇમ રિપોર્ટિંગ શરૂ થાય છે. પરંતુ જો કોઈ સમયે, ઉદાહરણ તરીકે, રાત્રે કોઈ કાર્ય ચાલી રહ્યું હતું, તો એક OOM-કિલર આવ્યો અને બળજબરીથી PostgreSQL ચાઈલ્ડ પ્રક્રિયાને સમાપ્ત કરી, તો આ કિસ્સામાં PostgreSQL બધા ક્લાયંટનું કનેક્શન સમાપ્ત કરે છે, શાર્ડેડ મેમરી એરિયા રીસેટ કરે છે અને પુનઃપ્રાપ્તિ શરૂ કરે છે. છેલ્લી ચેકપોઇન્ટ. અને જ્યારે ચેકપૉઇન્ટમાંથી આ પુનઃપ્રાપ્તિ ચાલે છે, ત્યારે ડેટાબેઝ કનેક્શન્સ સ્વીકારતું નથી, એટલે કે આ પરિસ્થિતિનું મૂલ્યાંકન ડાઉનટાઇમ તરીકે કરી શકાય છે. પરંતુ અપટાઇમ કાઉન્ટર રીસેટ કરવામાં આવશે નહીં, કારણ કે તે પ્રથમ ક્ષણથી જ પોસ્ટમાસ્ટર સ્ટાર્ટઅપ સમયને ધ્યાનમાં લે છે. તેથી, આવી પરિસ્થિતિઓને અવગણી શકાય છે.

તમારે વેક્યૂમ કામદારોની સંખ્યા પર પણ નજર રાખવી જોઈએ. શું દરેકને ખબર છે કે PostgreSQL માં ઓટોવેક્યુમ શું છે? PostgreSQL માં આ એક રસપ્રદ સબસિસ્ટમ છે. તેના વિશે ઘણા લેખો લખવામાં આવ્યા છે, ઘણા અહેવાલો બનાવવામાં આવ્યા છે. શૂન્યાવકાશ વિશે ઘણી ચર્ચાઓ છે અને તે કેવી રીતે કાર્ય કરવું જોઈએ. ઘણા તેને જરૂરી અનિષ્ટ માને છે. પરંતુ તે કેવી રીતે છે. આ કચરો કલેક્ટરનો એક પ્રકારનો એનાલોગ છે જે પંક્તિઓના જૂના સંસ્કરણોને સાફ કરે છે જે કોઈપણ વ્યવહાર માટે જરૂરી નથી અને નવી પંક્તિઓ માટે કોષ્ટકો અને અનુક્રમણિકાઓમાં જગ્યા ખાલી કરે છે.

તમારે તેનું નિરીક્ષણ કરવાની શા માટે જરૂર છે? કારણ કે શૂન્યાવકાશ ક્યારેક ખૂબ જ દુઃખ પહોંચાડે છે. તે મોટા પ્રમાણમાં સંસાધનોનો ઉપયોગ કરે છે અને પરિણામે ક્લાયંટ વિનંતીઓ પીડાય છે.

અને તેનું નિરીક્ષણ pg_stat_activity વ્યુ દ્વારા થવુ જોઈએ, જેના વિશે હું આગળના વિભાગમાં વાત કરીશ. આ દૃશ્ય ડેટાબેઝમાં વર્તમાન પ્રવૃત્તિ દર્શાવે છે. અને આ પ્રવૃત્તિ દ્વારા આપણે અત્યારે કામ કરી રહેલા શૂન્યાવકાશની સંખ્યાને ટ્રેક કરી શકીએ છીએ. અમે શૂન્યાવકાશને ટ્રૅક કરી શકીએ છીએ અને જોઈ શકીએ છીએ કે જો આપણે મર્યાદા ઓળંગી ગઈ હોય, તો આ પોસ્ટગ્રેએસક્યુએલ સેટિંગ્સમાં જોવાનું અને કોઈક રીતે વેક્યૂમના ઑપરેશનને ઑપ્ટિમાઇઝ કરવાનું એક કારણ છે.

PostgreSQL વિશે બીજી બાબત એ છે કે PostgreSQL લાંબા વ્યવહારોથી ખૂબ બીમાર છે. ખાસ કરીને એવા વ્યવહારોમાંથી કે જે લાંબા સમય સુધી અટકી જાય છે અને કંઈ કરતા નથી. આ કહેવાતા સ્ટેટ આઈડલ-ઈન-ટ્રાન્ઝેક્શન છે. આવા વ્યવહાર તાળાઓ ધરાવે છે અને વેક્યૂમને કામ કરતા અટકાવે છે. અને પરિણામે, કોષ્ટકો ફૂલે છે અને કદમાં વધારો કરે છે. અને આ કોષ્ટકો સાથે કામ કરતી ક્વેરીઝ ધીમી ગતિએ કામ કરવાનું શરૂ કરે છે, કારણ કે તમારે મેમરીથી ડિસ્ક અને બેક સુધી પંક્તિઓના તમામ જૂના સંસ્કરણોને પાવડો કરવાની જરૂર છે. તેથી, સમય, સૌથી લાંબા વ્યવહારોનો સમયગાળો, સૌથી લાંબી વેક્યૂમ વિનંતીઓનું પણ નિરીક્ષણ કરવું જરૂરી છે. અને જો આપણે કેટલીક પ્રક્રિયાઓ જોઈએ જે ખૂબ લાંબા સમયથી ચાલી રહી છે, OLTP લોડ માટે પહેલાથી જ 10-20-30 મિનિટથી વધુ, તો આપણે તેના પર ધ્યાન આપવાની જરૂર છે અને તેને બળપૂર્વક સમાપ્ત કરવાની જરૂર છે, અથવા એપ્લિકેશનને ઑપ્ટિમાઇઝ કરવાની જરૂર છે જેથી તેઓ કહેવામાં આવતું નથી અને લાંબા સમય સુધી અટકી જતા નથી. વિશ્લેષણાત્મક વર્કલોડ માટે, 10-20-30 મિનિટ સામાન્ય છે; ત્યાં વધુ લાંબી પણ છે.

આગળ અમારી પાસે કનેક્ટેડ ક્લાયન્ટ્સ સાથેનો વિકલ્પ છે. જ્યારે અમે પહેલેથી જ ડેશબોર્ડ બનાવ્યું હોય, તેના પર મુખ્ય સુલભતા મેટ્રિક્સ પોસ્ટ કર્યા હોય, ત્યારે અમે ત્યાં કનેક્ટેડ ક્લાયન્ટ્સ વિશે વધારાની માહિતી પણ ઉમેરી શકીએ છીએ.

કનેક્ટેડ ક્લાયન્ટ્સ વિશેની માહિતી મહત્વપૂર્ણ છે કારણ કે, PostgreSQL પરિપ્રેક્ષ્યમાં, ક્લાયંટ અલગ છે. સારા ગ્રાહકો છે અને ખરાબ ગ્રાહકો છે.

એક સરળ ઉદાહરણ. ક્લાયન્ટ દ્વારા હું એપ્લિકેશનને સમજું છું. એપ્લિકેશન ડેટાબેઝ સાથે જોડાયેલ છે અને તરત જ ત્યાં તેની વિનંતીઓ મોકલવાનું શરૂ કરે છે, ડેટાબેઝ પ્રક્રિયા કરે છે અને તેને એક્ઝિક્યુટ કરે છે અને ક્લાયન્ટને પરિણામો પરત કરે છે. આ સારા અને સાચા ગ્રાહકો છે.

એવી પરિસ્થિતિઓ છે જ્યારે ક્લાયંટ કનેક્ટ થાય છે, તે કનેક્શન ધરાવે છે, પરંતુ કંઈ કરતું નથી. તે નિષ્ક્રિય સ્થિતિમાં છે.

પરંતુ ખરાબ ગ્રાહકો છે. ઉદાહરણ તરીકે, તે જ ક્લાયંટ કનેક્ટેડ, ટ્રાન્ઝેક્શન ખોલ્યું, ડેટાબેઝમાં કંઈક કર્યું અને પછી કોડમાં ગયો, ઉદાહરણ તરીકે, બાહ્ય સ્ત્રોતને ઍક્સેસ કરવા અથવા ત્યાં પ્રાપ્ત ડેટાની પ્રક્રિયા કરવા માટે. પરંતુ તે જ સમયે, તેણે વ્યવહાર બંધ કર્યો ન હતો. અને ટ્રાન્ઝેક્શન ડેટાબેઝમાં અટકી જાય છે અને લાઇન પર લોક ધરાવે છે. આ એક ખરાબ સ્થિતિ છે. અને જો અચાનક કોઈ અપવાદ સાથે પોતાની અંદર ક્યાંક એપ્લિકેશન નિષ્ફળ જાય, તો પછી વ્યવહાર ખૂબ લાંબા સમય સુધી ખુલ્લો રહી શકે છે. અને આ પોસ્ટગ્રેએસક્યુએલની કામગીરીને સીધી અસર કરે છે. PostgreSQL ધીમી ચાલશે. તેથી, આવા ગ્રાહકોને સમયસર ટ્રેક કરવા અને તેમના કામને બળપૂર્વક સમાપ્ત કરવું મહત્વપૂર્ણ છે. અને તમારે તમારી એપ્લિકેશનને ઑપ્ટિમાઇઝ કરવાની જરૂર છે જેથી આવી કોઈ પરિસ્થિતિઓ ન હોય.

અન્ય ખરાબ ગ્રાહકો રાહ જોઈ રહ્યા છે. પરંતુ તેઓ સંજોગોને કારણે ખરાબ થઈ જાય છે. ઉદાહરણ તરીકે, એક સરળ નિષ્ક્રિય વ્યવહાર: તે કોઈ વ્યવહાર ખોલી શકે છે, કેટલીક લાઇન પર તાળાઓ લઈ શકે છે, પછી કોડમાં ક્યાંક તે નિષ્ફળ જશે, અટકી ગયેલ વ્યવહાર છોડીને. અન્ય ક્લાયંટ આવશે અને તે જ ડેટાની વિનંતી કરશે, પરંતુ તે એક લોકનો સામનો કરશે, કારણ કે તે હેંગિંગ ટ્રાન્ઝેક્શન પહેલાથી જ કેટલીક જરૂરી પંક્તિઓ પર તાળાઓ ધરાવે છે. અને બીજો ટ્રાન્ઝેક્શન પ્રથમ ટ્રાન્ઝેક્શન પૂર્ણ થવાની રાહ જોઈને અટકી જશે અથવા એડમિનિસ્ટ્રેટર દ્વારા તેને બળજબરીથી બંધ કરશે. તેથી, બાકી વ્યવહારો ડેટાબેઝ કનેક્શન મર્યાદા એકઠા કરી શકે છે અને ભરી શકે છે. અને જ્યારે મર્યાદા પૂર્ણ થઈ જાય, ત્યારે એપ્લિકેશન ડેટાબેઝ સાથે કામ કરી શકશે નહીં. આ પ્રોજેક્ટ માટે પહેલેથી જ કટોકટીની સ્થિતિ છે. તેથી, ખરાબ ગ્રાહકોને ટ્રૅક કરવાની અને સમયસર જવાબ આપવાની જરૂર છે.

મોનિટરિંગનું બીજું ઉદાહરણ. અને અહીં પહેલેથી જ યોગ્ય ડેશબોર્ડ છે. ઉપરોક્ત જોડાણો વિશે માહિતી છે. ડીબી કનેક્શન - 8 ટુકડાઓ. અને તે બધા છે. કયા ક્લાયન્ટ્સ સક્રિય છે, કયા ક્લાયન્ટ્સ ફક્ત નિષ્ક્રિય છે, કંઈ કરી રહ્યા નથી તે વિશે અમારી પાસે કોઈ માહિતી નથી. પેન્ડિંગ ટ્રાન્ઝેક્શન્સ અને પેન્ડિંગ કનેક્શન્સ વિશે કોઈ માહિતી નથી, એટલે કે આ એક આંકડો છે જે કનેક્શન્સની સંખ્યા દર્શાવે છે અને બસ. અને પછી તમારા માટે અનુમાન કરો.

તદનુસાર, આ માહિતીને મોનિટરિંગમાં ઉમેરવા માટે, તમારે pg_stat_activity સિસ્ટમ દૃશ્યને ઍક્સેસ કરવાની જરૂર છે. જો તમે PostgreSQL માં ઘણો સમય પસાર કરો છો, તો આ એક ખૂબ જ સારો દેખાવ છે જે તમારા મિત્ર બનવો જોઈએ, કારણ કે તે PostgreSQL માં વર્તમાન પ્રવૃત્તિ દર્શાવે છે, એટલે કે તેમાં શું થઈ રહ્યું છે. દરેક પ્રક્રિયા માટે એક અલગ લાઇન છે જે આ પ્રક્રિયા વિશેની માહિતી દર્શાવે છે: કયા હોસ્ટથી કનેક્શન કરવામાં આવ્યું હતું, કયા વપરાશકર્તા હેઠળ, કયા નામ હેઠળ, વ્યવહાર ક્યારે શરૂ થયો હતો, હાલમાં કઈ વિનંતી ચાલી રહી છે, કઈ વિનંતી છેલ્લે એક્ઝિક્યુટ કરવામાં આવી હતી. અને, તે મુજબ, અમે સ્ટેટ ફીલ્ડનો ઉપયોગ કરીને ક્લાયંટની સ્થિતિનું મૂલ્યાંકન કરી શકીએ છીએ. સાપેક્ષ રીતે કહીએ તો, અમે આ ક્ષેત્ર દ્વારા જૂથબદ્ધ કરી શકીએ છીએ અને તે આંકડાઓ કે જે હાલમાં ડેટાબેઝમાં છે અને ડેટાબેઝમાં આ સ્ટેટ ધરાવતા જોડાણોની સંખ્યા મેળવી શકીએ છીએ. અને અમે પહેલાથી પ્રાપ્ત નંબરો અમારા મોનિટરિંગમાં મોકલી શકીએ છીએ અને તેના આધારે આલેખ દોરી શકીએ છીએ.
વ્યવહારની અવધિનું મૂલ્યાંકન કરવું પણ મહત્વપૂર્ણ છે. મેં પહેલેથી જ કહ્યું છે કે શૂન્યાવકાશની અવધિનું મૂલ્યાંકન કરવું મહત્વપૂર્ણ છે, પરંતુ વ્યવહારોનું મૂલ્યાંકન તે જ રીતે કરવામાં આવે છે. ત્યાં xact_start અને query_start ફીલ્ડ છે. તેઓ, પ્રમાણમાં બોલતા, વ્યવહારનો પ્રારંભ સમય અને વિનંતીનો પ્રારંભ સમય દર્શાવે છે. અમે now() ફંક્શન લઈએ છીએ, જે વર્તમાન ટાઈમસ્ટેમ્પ દર્શાવે છે અને ટ્રાન્ઝેક્શન બાદબાકી કરીએ છીએ અને ટાઈમસ્ટેમ્પની વિનંતી કરીએ છીએ. અને અમને વ્યવહારનો સમયગાળો, વિનંતીનો સમયગાળો મળે છે.

જો આપણે લાંબા વ્યવહારો જોતા હોઈએ, તો આપણે તેને પહેલાથી જ પૂર્ણ કરીશું. OLTP લોડ માટે, લાંબા વ્યવહારો પહેલાથી જ 1-2-3 મિનિટથી વધુ છે. OLAP વર્કલોડ માટે, લાંબા વ્યવહારો સામાન્ય છે, પરંતુ જો તે પૂર્ણ થવામાં બે કલાકથી વધુ સમય લે છે, તો આ પણ એક સંકેત છે કે આપણી પાસે ક્યાંક ત્રાંસી છે.

એકવાર ક્લાયંટ ડેટાબેઝ સાથે કનેક્ટ થઈ જાય, પછી તેઓ અમારા ડેટા સાથે કામ કરવાનું શરૂ કરે છે. તેઓ કોષ્ટકોને ઍક્સેસ કરે છે, તેઓ કોષ્ટકમાંથી ડેટા મેળવવા માટે ઇન્ડેક્સને ઍક્સેસ કરે છે. અને ગ્રાહકો આ ડેટા સાથે કેવી રીતે ક્રિયાપ્રતિક્રિયા કરે છે તેનું મૂલ્યાંકન કરવું મહત્વપૂર્ણ છે.

અમારા વર્કલોડનું મૂલ્યાંકન કરવા અને અમારા માટે કયા કોષ્ટકો "સૌથી ગરમ" છે તે સમજવા માટે આ જરૂરી છે. ઉદાહરણ તરીકે, આ એવી પરિસ્થિતિઓમાં જરૂરી છે જ્યાં આપણે અમુક પ્રકારના ઝડપી SSD સ્ટોરેજ પર "ગરમ" કોષ્ટકો મૂકવા માંગીએ છીએ. ઉદાહરણ તરીકે, કેટલાક આર્કાઇવ કોષ્ટકો કે જેનો આપણે લાંબા સમયથી ઉપયોગ કર્યો નથી તે અમુક પ્રકારના "કોલ્ડ" આર્કાઇવમાં, SATA ડ્રાઇવમાં ખસેડી શકાય છે અને તેમને ત્યાં રહેવા દો, તેઓને જરૂર મુજબ ઍક્સેસ કરવામાં આવશે.

કોઈપણ પ્રકાશન અને જમાવટ પછી વિસંગતતાઓ શોધવા માટે પણ આ ઉપયોગી છે. જણાવી દઈએ કે પ્રોજેક્ટે કેટલાક નવા ફીચર રજૂ કર્યા છે. ઉદાહરણ તરીકે, અમે ડેટાબેઝ સાથે કામ કરવા માટે નવી કાર્યક્ષમતા ઉમેરી છે. અને જો આપણે ટેબલ વપરાશ આલેખને કાવતરું કરીએ, તો આપણે આ આલેખ પર આ વિસંગતતાઓને સરળતાથી શોધી શકીએ છીએ. ઉદાહરણ તરીકે, બર્સ્ટ અપડેટ કરો અથવા બર્સ્ટ કાઢી નાખો. તે ખૂબ જ દૃશ્યમાન હશે.

તમે "ફ્લોટિંગ" આંકડાઓમાં વિસંગતતાઓ પણ શોધી શકો છો. તેનો અર્થ શું છે? PostgreSQL પાસે ખૂબ જ મજબૂત અને ખૂબ જ સારું ક્વેરી શેડ્યૂલર છે. અને વિકાસકર્તાઓ તેના વિકાસ માટે ઘણો સમય ફાળવે છે. તે કેવી રીતે કામ કરે છે? સારી યોજનાઓ બનાવવા માટે, PostgreSQL ચોક્કસ સમય અંતરાલ અને ચોક્કસ આવર્તન સાથે કોષ્ટકોમાં ડેટાના વિતરણ પર આંકડા એકત્રિત કરે છે. આ સૌથી સામાન્ય મૂલ્યો છે: અનન્ય મૂલ્યોની સંખ્યા, કોષ્ટકમાં NULL વિશેની માહિતી, ઘણી બધી માહિતી.

આ આંકડાઓના આધારે, આયોજક ઘણી ક્વેરી બનાવે છે, સૌથી શ્રેષ્ઠ પસંદ કરે છે અને આ ક્વેરી પ્લાનનો ઉપયોગ ક્વેરી પોતે જ એક્ઝિક્યુટ કરવા અને ડેટા પરત કરવા માટે કરે છે.

અને એવું બને છે કે આંકડા "ફ્લોટ" થાય છે. કોષ્ટકમાં ગુણવત્તા અને જથ્થાનો ડેટા કોઈક રીતે બદલાયો હતો, પરંતુ આંકડા એકત્રિત કરવામાં આવ્યા ન હતા. અને રચાયેલી યોજનાઓ શ્રેષ્ઠ ન હોઈ શકે. અને જો અમારી યોજનાઓ કોષ્ટકોના આધારે એકત્રિત કરવામાં આવેલા મોનિટરિંગના આધારે સબઓપ્ટિમલ હોવાનું બહાર આવે છે, તો અમે આ વિસંગતતાઓને જોઈ શકીશું. ઉદાહરણ તરીકે, ક્યાંક ડેટા ગુણાત્મક રીતે બદલાયો અને અનુક્રમણિકાને બદલે, કોષ્ટકમાંથી ક્રમિક પાસનો ઉપયોગ થવા લાગ્યો, એટલે કે. જો કોઈ ક્વેરી માટે માત્ર 100 પંક્તિઓ પરત કરવાની જરૂર હોય (ત્યાં 100 ની મર્યાદા છે), તો આ ક્વેરી માટે સંપૂર્ણ શોધ કરવામાં આવશે. અને આ હંમેશા પ્રદર્શન પર ખૂબ જ ખરાબ અસર કરે છે.

અને આપણે આને મોનીટરીંગમાં જોઈ શકીએ છીએ. અને પહેલેથી જ આ ક્વેરી જુઓ, તેના માટે સમજાવો, આંકડા એકત્રિત કરો, એક નવો વધારાનો ઇન્ડેક્સ બનાવો. અને પહેલાથી જ આ સમસ્યાનો જવાબ આપો. એટલા માટે તે મહત્વનું છે.

મોનિટરિંગનું બીજું ઉદાહરણ. મને લાગે છે કે ઘણા લોકોએ તેમને ઓળખ્યા કારણ કે તે ખૂબ જ લોકપ્રિય છે. કોણ તેનો ઉપયોગ તેમના પ્રોજેક્ટ્સમાં કરે છે પ્રોમિથિયસ? પ્રોમિથિયસ સાથે જોડાણમાં આ ઉત્પાદનનો ઉપયોગ કોણ કરે છે? હકીકત એ છે કે આ મોનીટરીંગના પ્રમાણભૂત રીપોઝીટરીમાં PostgreSQL સાથે કામ કરવા માટે ડેશબોર્ડ છે - postgres_exporter પ્રોમિથિયસ. પરંતુ એક ખરાબ વિગત છે.

ઘણા ગ્રાફ છે. અને બાઇટ્સ એકતા તરીકે સૂચવવામાં આવે છે, એટલે કે ત્યાં 5 ગ્રાફ છે. આ ડેટા દાખલ કરો, ડેટા અપડેટ કરો, ડેટા કાઢી નાખો, ડેટા મેળવો અને રીટર્ન ડેટા છે. એકમ માપ બાઇટ્સ છે. પરંતુ વાત એ છે કે PostgreSQL માં આંકડા ટ્યુપલ (પંક્તિઓ) માં ડેટા આપે છે. અને, તદનુસાર, આ આલેખ તમારા વર્કલોડને ઘણી વખત, દસેક વખત ઓછો આંકવાની ખૂબ જ સારી રીત છે, કારણ કે ટ્યૂપલ એ બાઈટ નથી, ટ્યૂપલ એ સ્ટ્રિંગ છે, તે ઘણી બાઇટ્સ છે અને તે હંમેશા વેરિયેબલ લંબાઈની હોય છે. એટલે કે, ટ્યુપલ્સનો ઉપયોગ કરીને બાઇટ્સમાં વર્કલોડની ગણતરી કરવી એ અવાસ્તવિક કાર્ય છે અથવા ખૂબ મુશ્કેલ છે. તેથી, જ્યારે તમે ડેશબોર્ડ અથવા બિલ્ટ-ઇન મોનિટરિંગનો ઉપયોગ કરો છો, ત્યારે તે સમજવું હંમેશા મહત્વપૂર્ણ છે કે તે યોગ્ય રીતે કાર્ય કરે છે અને તમને યોગ્ય રીતે આકારણી કરેલ ડેટા પરત કરે છે.

આ કોષ્ટકો પર આંકડા કેવી રીતે મેળવવું? આ હેતુ માટે, PostgreSQL પાસે ચોક્કસ કુટુંબના મંતવ્યો છે. અને મુખ્ય દૃશ્ય છે pg_stat_user_tables. User_tables - આનો અર્થ છે વપરાશકર્તા વતી બનાવેલ કોષ્ટકો. તેનાથી વિપરીત, ત્યાં સિસ્ટમ દૃશ્યો છે જેનો ઉપયોગ PostgreSQL દ્વારા કરવામાં આવે છે. અને ત્યાં એક સારાંશ કોષ્ટક Alltables છે, જેમાં સિસ્ટમ અને વપરાશકર્તા બંનેનો સમાવેશ થાય છે. તમે તેમાંના કોઈપણથી શરૂ કરી શકો છો જે તમને સૌથી વધુ ગમે છે.

ઉપરોક્ત ફીલ્ડ્સનો ઉપયોગ કરીને તમે દાખલ, અપડેટ અને કાઢી નાખવાની સંખ્યાનો અંદાજ લગાવી શકો છો. મેં ઉપયોગમાં લીધેલા ડેશબોર્ડનું ઉદાહરણ વર્કલોડની લાક્ષણિકતાઓનું મૂલ્યાંકન કરવા માટે આ ક્ષેત્રોનો ઉપયોગ કરે છે. તેથી, અમે તેમના પર પણ નિર્માણ કરી શકીએ છીએ. પરંતુ તે યાદ રાખવું યોગ્ય છે કે આ ટ્યુપલ્સ છે, બાઇટ્સ નથી, તેથી અમે તેને ફક્ત બાઇટ્સમાં કરી શકતા નથી.

આ ડેટાના આધારે, અમે કહેવાતા TopN કોષ્ટકો બનાવી શકીએ છીએ. ઉદાહરણ તરીકે, ટોપ-5, ટોપ-10. અને તમે તે હોટ કોષ્ટકોને ટ્રૅક કરી શકો છો જે અન્ય કરતા વધુ રિસાયકલ કરવામાં આવે છે. ઉદાહરણ તરીકે, દાખલ કરવા માટે 5 "ગરમ" કોષ્ટકો. અને આ TopN કોષ્ટકોનો ઉપયોગ કરીને અમે અમારા વર્કલોડનું મૂલ્યાંકન કરીએ છીએ અને કોઈપણ પ્રકાશન, અપડેટ્સ અને જમાવટ પછી વર્કલોડના વિસ્ફોટનું મૂલ્યાંકન કરી શકીએ છીએ.

કોષ્ટકના કદનું મૂલ્યાંકન કરવું પણ મહત્વપૂર્ણ છે, કારણ કે કેટલીકવાર વિકાસકર્તાઓ એક નવી સુવિધા રજૂ કરે છે, અને અમારા કોષ્ટકો તેમના મોટા કદમાં ફૂલવા લાગે છે, કારણ કે તેઓએ વધારાની માહિતી ઉમેરવાનું નક્કી કર્યું હતું, પરંતુ આ કેવી રીતે થશે તેની આગાહી કરી નથી. ડેટાબેઝના કદને અસર કરે છે. આવા કિસ્સાઓ પણ આપણા માટે આશ્ચર્યજનક છે.

અને હવે તમારા માટે એક નાનો પ્રશ્ન. જ્યારે તમે તમારા ડેટાબેઝ સર્વર પર લોડ જોશો ત્યારે કયો પ્રશ્ન ઊભો થાય છે? તમારી પાસે આગળનો પ્રશ્ન શું છે?

પરંતુ વાસ્તવમાં પ્રશ્ન નીચે મુજબ ઉદભવે છે. લોડનું કારણ શું વિનંતીઓ છે? એટલે કે, લોડને કારણે થતી પ્રક્રિયાઓને જોવાનું રસપ્રદ નથી. તે સ્પષ્ટ છે કે જો હોસ્ટ પાસે ડેટાબેઝ છે, તો ડેટાબેઝ ત્યાં ચાલી રહ્યો છે અને તે સ્પષ્ટ છે કે ફક્ત ડેટાબેઝનો ત્યાં નિકાલ કરવામાં આવશે. જો આપણે ટોપ ખોલીએ, તો આપણે ત્યાં PostgreSQL માં પ્રક્રિયાઓની યાદી જોશું જે કંઈક કરી રહી છે. તેઓ શું કરી રહ્યા છે તે ટોચ પરથી સ્પષ્ટ થશે નહીં.

તદનુસાર, તમારે તે ક્વેરીઝ શોધવાની જરૂર છે જે સૌથી વધુ લોડનું કારણ બને છે, કારણ કે ટ્યુનિંગ ક્વેરીઝ, નિયમ તરીકે, પોસ્ટગ્રેએસક્યુએલ અથવા ઓપરેટિંગ સિસ્ટમ ગોઠવણીને ટ્યુન કરવા અથવા હાર્ડવેરને ટ્યુન કરવા કરતાં વધુ નફો આપે છે. મારા અંદાજ મુજબ, આ લગભગ 80-85-90% છે. અને આ ખૂબ ઝડપથી કરવામાં આવે છે. રૂપરેખાંકન સુધારવા, પુનઃપ્રારંભ સુનિશ્ચિત કરવા, ખાસ કરીને જો ડેટાબેઝ પુનઃપ્રારંભ કરી શકાતો નથી, અથવા હાર્ડવેર ઉમેરવા કરતાં વિનંતિ સુધારવાનું વધુ ઝડપી છે. આ ક્વેરીમાંથી વધુ સારું પરિણામ મેળવવા માટે ક્યાંક ક્વેરી ફરીથી લખવી અથવા ઇન્ડેક્સ ઉમેરવાનું સરળ છે.

તદનુસાર, વિનંતીઓ અને તેમની પર્યાપ્તતાનું નિરીક્ષણ કરવું જરૂરી છે. ચાલો મોનિટરિંગનું બીજું ઉદાહરણ લઈએ. અને અહીં પણ, ઉત્તમ દેખરેખ હોવાનું જણાય છે. પ્રતિકૃતિ પર માહિતી છે, થ્રુપુટ, અવરોધિત, સંસાધન ઉપયોગ પર માહિતી છે. બધું બરાબર છે, પરંતુ વિનંતીઓ પર કોઈ માહિતી નથી. અમારા ડેટાબેઝમાં કઈ ક્વેરી ચાલી રહી છે, તે કેટલા સમયથી ચાલી રહી છે, આમાંથી કેટલી ક્વેરી છે તે સ્પષ્ટ નથી. અમારી દેખરેખમાં હંમેશા આ માહિતી હોવી જરૂરી છે.

અને આ માહિતી મેળવવા માટે આપણે pg_stat_statements મોડ્યુલનો ઉપયોગ કરી શકીએ છીએ. તેના આધારે, તમે વિવિધ પ્રકારના ગ્રાફ બનાવી શકો છો. ઉદાહરણ તરીકે, તમે સૌથી વધુ વારંવાર આવતી ક્વેરીઝ પર માહિતી મેળવી શકો છો, એટલે કે, તે ક્વેરીઝ કે જે મોટાભાગે ચલાવવામાં આવે છે. હા, જમાવટ પછી તેને જોવા અને વિનંતીઓમાં કોઈ વધારો થયો છે કે કેમ તે સમજવું પણ ખૂબ ઉપયોગી છે.

તમે સૌથી લાંબી ક્વેરીઝને મોનિટર કરી શકો છો, એટલે કે, તે ક્વેરીઝ જે પૂર્ણ થવામાં સૌથી વધુ સમય લે છે. તેઓ પ્રોસેસર પર ચાલે છે, તેઓ I/O વાપરે છે. અમે કુલ_સમય, સરેરાશ_સમય, blk_write_time અને blk_read_time ફીલ્ડનો ઉપયોગ કરીને પણ આનું મૂલ્યાંકન કરી શકીએ છીએ.

અમે સંસાધનના ઉપયોગના સંદર્ભમાં સૌથી ભારે વિનંતીઓનું મૂલ્યાંકન અને નિરીક્ષણ કરી શકીએ છીએ, જે ડિસ્કમાંથી વાંચે છે, જે મેમરી સાથે કામ કરે છે, અથવા, તેનાથી વિપરીત, અમુક પ્રકારનો લેખન લોડ બનાવે છે.

અમે સૌથી ઉદાર વિનંતીઓનું મૂલ્યાંકન કરી શકીએ છીએ. આ એવી ક્વેરી છે જે મોટી સંખ્યામાં પંક્તિઓ પરત કરે છે. ઉદાહરણ તરીકે, આ અમુક વિનંતી હોઈ શકે છે જ્યાં તેઓ મર્યાદા સેટ કરવાનું ભૂલી ગયા હોય. અને તે ફક્ત કોષ્ટકની સંપૂર્ણ સામગ્રી અથવા ક્વેરી કરેલ કોષ્ટકોમાં ક્વેરી પરત કરે છે.

અને તમે અસ્થાયી ફાઇલો અથવા અસ્થાયી કોષ્ટકોનો ઉપયોગ કરતી ક્વેરીઝનું પણ નિરીક્ષણ કરી શકો છો.

અને અમારી પાસે હજુ પણ પૃષ્ઠભૂમિ પ્રક્રિયાઓ છે. પૃષ્ઠભૂમિ પ્રક્રિયાઓ મુખ્યત્વે ચેકપોઇન્ટ છે અથવા તેને ચેકપોઇન્ટ પણ કહેવામાં આવે છે, આ ઓટોવેક્યુમ અને પ્રતિકૃતિ છે.

મોનિટરિંગનું બીજું ઉદાહરણ. ડાબી બાજુએ મેન્ટેનન્સ ટેબ છે, તેના પર જાઓ અને કંઈક ઉપયોગી જોવાની આશા રાખો. પરંતુ અહીં ફક્ત વેક્યુમ ઓપરેશન અને આંકડા સંગ્રહનો સમય છે, વધુ કંઈ નથી. આ ખૂબ જ નબળી માહિતી છે, તેથી અમારા ડેટાબેઝમાં પૃષ્ઠભૂમિ પ્રક્રિયાઓ કેવી રીતે કાર્ય કરે છે અને તેમના કાર્યમાં કોઈ સમસ્યા છે કે કેમ તે વિશે અમારી પાસે હંમેશા માહિતી હોવી જરૂરી છે.

જ્યારે આપણે ચેકપોઈન્ટ્સ જોઈએ છીએ, ત્યારે આપણે યાદ રાખવું જોઈએ કે ચેકપોઈન્ટ્સ ગંદા પૃષ્ઠોને શાર્ડેડ મેમરી એરિયાથી ડિસ્ક પર ફ્લશ કરે છે, પછી ચેકપોઈન્ટ બનાવો. અને જો PostgreSQL અચાનક કટોકટીમાં બંધ થઈ જાય તો આ ચેકપોઈન્ટનો ઉપયોગ પુનઃપ્રાપ્તિ માટેના સ્થળ તરીકે થઈ શકે છે.

તદનુસાર, બધા "ગંદા" પૃષ્ઠોને ડિસ્ક પર ફ્લશ કરવા માટે, તમારે ચોક્કસ માત્રામાં લેખન કરવાની જરૂર છે. અને, એક નિયમ તરીકે, મોટી માત્રામાં મેમરી ધરાવતી સિસ્ટમો પર, આ ઘણું છે. અને જો આપણે ટૂંકા અંતરાલમાં ઘણી વાર ચેકપોઇન્ટ કરીએ છીએ, તો ડિસ્કનું પ્રદર્શન ખૂબ જ નોંધપાત્ર રીતે ઘટશે. અને ક્લાયંટ વિનંતીઓ સંસાધનોના અભાવથી પીડાશે. તેઓ સંસાધનો માટે સ્પર્ધા કરશે અને ઉત્પાદકતાનો અભાવ હશે.

તદનુસાર, pg_stat_bgwriter દ્વારા ઉલ્લેખિત ક્ષેત્રોનો ઉપયોગ કરીને અમે ચેકપોઇન્ટની સંખ્યાને મોનિટર કરી શકીએ છીએ. અને જો અમારી પાસે ચોક્કસ સમયગાળા દરમિયાન (10-15-20 મિનિટમાં, અડધા કલાકમાં) ઘણી બધી ચેકપોઇન્ટ્સ હોય, ઉદાહરણ તરીકે, 3-4-5, તો આ પહેલેથી જ સમસ્યા હોઈ શકે છે. અને તમારે પહેલાથી જ ડેટાબેઝમાં જોવાની જરૂર છે, રૂપરેખાંકનમાં જુઓ, ચેકપોઇન્ટ્સની આવી વિપુલતાનું કારણ શું છે. કદાચ કોઈ પ્રકારનું મોટું રેકોર્ડિંગ ચાલી રહ્યું છે. અમે પહેલેથી જ વર્કલોડનું મૂલ્યાંકન કરી શકીએ છીએ, કારણ કે અમે પહેલેથી જ વર્કલોડ ગ્રાફ ઉમેર્યા છે. અમે પહેલાથી જ ચેકપોઇન્ટ પેરામીટર્સમાં ફેરફાર કરી શકીએ છીએ અને ખાતરી કરી શકીએ છીએ કે તેઓ ક્વેરી કામગીરીને મોટા પ્રમાણમાં અસર કરતા નથી.

હું ફરીથી ઓટોવેક્યુમ પર પાછો આવી રહ્યો છું કારણ કે તે એક એવી વસ્તુ છે, જેમ કે મેં કહ્યું, તે સરળતાથી ડિસ્ક અને ક્વેરી પ્રદર્શન બંને ઉમેરી શકે છે, તેથી ઓટોવેક્યુમની માત્રાનો અંદાજ કાઢવો હંમેશા મહત્વપૂર્ણ છે.

ડેટાબેઝમાં ઓટોવેક્યુમ કામદારોની સંખ્યા મર્યાદિત છે. મૂળભૂત રીતે, તેમાંના ત્રણ હોય છે, તેથી જો અમારી પાસે હંમેશા ડેટાબેઝમાં ત્રણ કામદારો કામ કરતા હોય, તો આનો અર્થ એ છે કે અમારું ઑટોવેક્યુમ ગોઠવેલું નથી, અમારે મર્યાદા વધારવાની, ઑટોવેક્યુમ સેટિંગ્સમાં સુધારો કરવાની અને ગોઠવણીમાં આવવાની જરૂર છે.
આપણા માટે કયા વેક્યુમ કામદારો કામ કરે છે તેનું મૂલ્યાંકન કરવું અગત્યનું છે. કાં તો તે વપરાશકર્તા દ્વારા લોન્ચ કરવામાં આવ્યું હતું, ડીબીએ આવ્યું અને તેના હાથ વડે અમુક પ્રકારનું વેક્યૂમ લોન્ચ કર્યું, અને આનાથી એક ભાર ઊભો થયો. અમને થોડી સમસ્યા છે. અથવા આ શૂન્યાવકાશની સંખ્યા છે જે ટ્રાન્ઝેક્શન કાઉન્ટરને અનસ્ક્રૂ કરે છે. PostgreSQL ના કેટલાક સંસ્કરણો માટે, આ ખૂબ જ ભારે શૂન્યાવકાશ છે. અને તેઓ સરળતાથી પર્ફોર્મન્સ ઉમેરી શકે છે કારણ કે તેઓ આખા ટેબલની બાદબાકી કરી રહ્યાં છે, આ કોષ્ટકમાંના તમામ બ્લોક્સને સ્કેન કરી રહ્યાં છે.

અને, અલબત્ત, વેક્યૂમનો સમયગાળો. જો આપણી પાસે લાંબા સમય સુધી ચાલતા શૂન્યાવકાશ છે જે ખૂબ લાંબા સમય સુધી ચાલે છે, તો આનો અર્થ એ છે કે આપણે ફરીથી વેક્યૂમ ગોઠવણી પર ધ્યાન આપવાની જરૂર છે અને કદાચ તેની સેટિંગ્સ પર પુનર્વિચાર કરવાની જરૂર છે. કારણ કે જ્યારે શૂન્યાવકાશ ટેબલ પર લાંબા સમય સુધી (3-4 કલાક) કામ કરે છે ત્યારે પરિસ્થિતિ ઊભી થઈ શકે છે, પરંતુ શૂન્યાવકાશ કામ કરી રહ્યું હતું તે દરમિયાન, મૃત પંક્તિઓનો મોટો જથ્થો ફરીથી ટેબલમાં એકઠા થવામાં વ્યવસ્થાપિત થયો. અને જલદી શૂન્યાવકાશ પૂર્ણ થાય છે, તેણે આ ટેબલને ફરીથી વેક્યૂમ કરવાની જરૂર છે. અને આપણે એવી પરિસ્થિતિમાં આવીએ છીએ - એક અનંત શૂન્યાવકાશ. અને આ કિસ્સામાં, શૂન્યાવકાશ તેના કાર્યનો સામનો કરતું નથી, અને કોષ્ટકો ધીમે ધીમે કદમાં ફૂલવા લાગે છે, જો કે તેમાં ઉપયોગી ડેટાનું પ્રમાણ સમાન રહે છે. તેથી, લાંબા શૂન્યાવકાશ દરમિયાન, અમે હંમેશા રૂપરેખાંકનને જોઈએ છીએ અને તેને ઑપ્ટિમાઇઝ કરવાનો પ્રયાસ કરીએ છીએ, પરંતુ તે જ સમયે જેથી ક્લાયંટ વિનંતીઓના પ્રદર્શનને નુકસાન ન થાય.

આજકાલ વ્યવહારીક રીતે કોઈ PostgreSQL ઇન્સ્ટોલેશન નથી કે જેમાં સ્ટ્રીમિંગ પ્રતિકૃતિ ન હોય. પ્રતિકૃતિ એ ડેટાને માસ્ટરથી પ્રતિકૃતિમાં ખસેડવાની પ્રક્રિયા છે.

PostgreSQL માં પ્રતિકૃતિ ટ્રાન્ઝેક્શન લોગ દ્વારા કરવામાં આવે છે. વિઝાર્ડ ટ્રાન્ઝેક્શન લોગ જનરેટ કરે છે. ટ્રાન્ઝેક્શન લોગ પ્રતિકૃતિના નેટવર્ક કનેક્શન પર મુસાફરી કરે છે, અને પછી તે પ્રતિકૃતિ પર પુનઃઉત્પાદિત થાય છે. તે સરળ છે.

તદનુસાર, pg_stat_replication દૃશ્યનો ઉપયોગ પ્રતિકૃતિ લેગને મોનિટર કરવા માટે થાય છે. પરંતુ તેની સાથે બધું સરળ નથી. સંસ્કરણ 10 માં, દૃશ્યમાં ઘણા ફેરફારો થયા છે. સૌપ્રથમ, કેટલાક ક્ષેત્રોનું નામ બદલવામાં આવ્યું છે. અને કેટલાક ક્ષેત્રો ઉમેરવામાં આવ્યા છે. સંસ્કરણ 10 માં, ફીલ્ડ્સ દેખાયા જે તમને સેકંડમાં પ્રતિકૃતિ લેગનો અંદાજ કાઢવા દે છે. તે ખૂબ જ આરામદાયક છે. વર્ઝન 10 પહેલા, બાઈટ્સમાં પ્રતિકૃતિ લેગનો અંદાજ લગાવવો શક્ય હતો. આ વિકલ્પ સંસ્કરણ 10 માં રહે છે, એટલે કે તમે તમારા માટે વધુ અનુકૂળ હોય તે પસંદ કરી શકો છો - બાઈટમાં લેગનો અંદાજ કાઢો અથવા સેકંડમાં લેગનો અંદાજ કાઢો. ઘણા લોકો બંને કરે છે.

પરંતુ તેમ છતાં, પ્રતિકૃતિ લેગનું મૂલ્યાંકન કરવા માટે, તમારે વ્યવહારમાં લોગની સ્થિતિ જાણવાની જરૂર છે. અને આ ટ્રાન્ઝેક્શન લોગ પોઝિશન્સ pg_stat_replication વ્યૂમાં બરાબર છે. સાપેક્ષ રીતે કહીએ તો, આપણે pg_xlog_location_diff() ફંક્શનનો ઉપયોગ કરીને ટ્રાન્ઝેક્શન લોગમાં બે પોઈન્ટ લઈ શકીએ છીએ. તેમની વચ્ચેના ડેલ્ટાની ગણતરી કરો અને બાઇટ્સમાં પ્રતિકૃતિ લેગ મેળવો. તે ખૂબ જ અનુકૂળ અને સરળ છે.

સંસ્કરણ 10 માં, આ કાર્યનું નામ બદલીને pg_wal_lsn_diff() કરવામાં આવ્યું હતું. સામાન્ય રીતે, તમામ કાર્યો, દૃશ્યો અને ઉપયોગિતાઓમાં જ્યાં "xlog" શબ્દ દેખાય છે, તે મૂલ્ય "wal" સાથે બદલવામાં આવ્યો હતો. આ દૃશ્યો અને કાર્યો બંનેને લાગુ પડે છે. આ એક એવી નવીનતા છે.

ઉપરાંત, સંસ્કરણ 10 માં, રેખાઓ ઉમેરવામાં આવી હતી જે ખાસ કરીને લેગ દર્શાવે છે. આ રાઈટ લેગ, ફ્લશ લેગ, રીપ્લે લેગ છે. એટલે કે આ બાબતો પર નજર રાખવી જરૂરી છે. જો આપણે જોઈએ કે અમારી પાસે પ્રતિકૃતિ વિરામ છે, તો અમારે તે શા માટે દેખાયું, તે ક્યાંથી આવ્યું અને સમસ્યાને ઠીક કરવાની જરૂર છે.

સિસ્ટમ મેટ્રિક્સ સાથે લગભગ બધું જ ક્રમમાં છે. જ્યારે કોઈપણ દેખરેખ શરૂ થાય છે, ત્યારે તે સિસ્ટમ મેટ્રિક્સથી શરૂ થાય છે. આ પ્રોસેસર્સ, મેમરી, સ્વેપ, નેટવર્ક અને ડિસ્કનો નિકાલ છે. જો કે, ઘણા પરિમાણો મૂળભૂત રીતે ત્યાં નથી.

જો બધું રિસાયક્લિંગ પ્રક્રિયા સાથે ક્રમમાં છે, તો ડિસ્ક રિસાયક્લિંગ સાથે સમસ્યાઓ છે. એક નિયમ તરીકે, મોનિટરિંગ ડેવલપર્સ થ્રુપુટ વિશે માહિતી ઉમેરે છે. તે iops અથવા બાઈટમાં હોઈ શકે છે. પરંતુ તેઓ લેટન્સી અને ડિસ્ક ઉપકરણોના ઉપયોગ વિશે ભૂલી જાય છે. આ વધુ મહત્વપૂર્ણ પરિમાણો છે જે અમને મૂલ્યાંકન કરવાની મંજૂરી આપે છે કે અમારી ડિસ્ક કેટલી લોડ છે અને તે કેટલી ધીમી છે. જો અમારી પાસે ઉચ્ચ વિલંબ છે, તો આનો અર્થ એ છે કે ડિસ્કમાં કેટલીક સમસ્યાઓ છે. જો અમારી પાસે ઉચ્ચ ઉપયોગ છે, તો તેનો અર્થ એ છે કે ડિસ્કનો સામનો કરી રહી નથી. આ થ્રુપુટ કરતાં વધુ સારી લાક્ષણિકતાઓ છે.

વધુમાં, આ આંકડાઓ /proc ફાઇલ સિસ્ટમમાંથી પણ મેળવી શકાય છે, જેમ કે રિસાયક્લિંગ પ્રોસેસરો માટે કરવામાં આવે છે. મને ખબર નથી કે આ માહિતી મોનિટરિંગમાં શા માટે ઉમેરવામાં આવતી નથી. પરંતુ તેમ છતાં, તમારા મોનિટરિંગમાં આ હોવું મહત્વપૂર્ણ છે.

આ જ નેટવર્ક ઇન્ટરફેસ પર લાગુ પડે છે. પેકેટોમાં, બાઈટ્સમાં નેટવર્ક થ્રુપુટ વિશે માહિતી છે, પરંતુ તેમ છતાં લેટન્સી વિશે કોઈ માહિતી નથી અને ઉપયોગ વિશે કોઈ માહિતી નથી, જો કે આ પણ ઉપયોગી માહિતી છે.

કોઈપણ દેખરેખમાં ખામીઓ હોય છે. અને તમે ગમે તે પ્રકારનું મોનિટરિંગ લો, તે હંમેશા કેટલાક માપદંડોને પૂર્ણ કરશે નહીં. પરંતુ તેમ છતાં, તેઓ વિકાસ કરી રહ્યા છે, નવી સુવિધાઓ અને નવી વસ્તુઓ ઉમેરવામાં આવી રહી છે, તેથી કંઈક પસંદ કરો અને તેને સમાપ્ત કરો.

અને સમાપ્ત કરવા માટે, તમારે હંમેશા ખ્યાલ હોવો જોઈએ કે આપેલા આંકડાનો અર્થ શું છે અને તમે સમસ્યાઓ હલ કરવા માટે તેનો ઉપયોગ કેવી રીતે કરી શકો છો.

અને કેટલાક મુખ્ય મુદ્દાઓ:

• તમારે હંમેશા ઉપલબ્ધતાની દેખરેખ રાખવી જોઈએ અને ડેશબોર્ડ્સ હોવા જોઈએ જેથી તમે ઝડપથી મૂલ્યાંકન કરી શકો કે ડેટાબેઝ સાથે બધું ક્રમમાં છે.
• ખરાબ ક્લાયંટને બહાર કાઢવા અને તેમને શૂટ કરવા માટે તમારે હંમેશા તમારા ડેટાબેઝ સાથે ક્લાયન્ટ્સ શું કામ કરી રહ્યા છે તેનો ખ્યાલ રાખવાની જરૂર છે.
• આ ક્લાયંટ ડેટા સાથે કેવી રીતે કાર્ય કરે છે તેનું મૂલ્યાંકન કરવું મહત્વપૂર્ણ છે. તમારે તમારા વર્કલોડ વિશે ખ્યાલ રાખવાની જરૂર છે.
• કયા પ્રશ્નોની મદદથી આ વર્કલોડ કેવી રીતે રચાય છે તેનું મૂલ્યાંકન કરવું અગત્યનું છે. તમે પ્રશ્નોનું મૂલ્યાંકન કરી શકો છો, તમે તેમને ઑપ્ટિમાઇઝ કરી શકો છો, તેમને રિફેક્ટ કરી શકો છો, તેમના માટે અનુક્રમણિકા બનાવી શકો છો. તે ખૂબ જ મહત્વપૂર્ણ છે.
• પૃષ્ઠભૂમિ પ્રક્રિયાઓ ક્લાયંટ વિનંતીઓ પર નકારાત્મક અસર કરી શકે છે, તેથી તે મોનિટર કરવું મહત્વપૂર્ણ છે કે તેઓ ઘણા સંસાધનોનો ઉપયોગ કરી રહ્યાં નથી.
• સિસ્ટમ મેટ્રિક્સ તમને તમારા સર્વરની ક્ષમતાને માપવા અને વધારવા માટેની યોજનાઓ બનાવવા દે છે, તેથી તેમને ટ્રૅક કરવું અને તેનું મૂલ્યાંકન કરવું પણ મહત્વપૂર્ણ છે.

જો તમને આ વિષયમાં રસ છે, તો પછી તમે આ લિંક્સને અનુસરી શકો છો.
http://bit.do/stats_collector - આ આંકડા કલેક્ટરના સત્તાવાર દસ્તાવેજો છે. તમામ આંકડાકીય દૃશ્યોનું વર્ણન અને તમામ ક્ષેત્રોનું વર્ણન છે. તમે તેમને વાંચી, સમજી અને વિશ્લેષણ કરી શકો છો. અને તેના આધારે, તમારા ગ્રાફ બનાવો અને તેને તમારા મોનિટરિંગમાં ઉમેરો.

ઉદાહરણ વિનંતીઓ:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

આ અમારી કોર્પોરેટ રીપોઝીટરી છે અને મારી પોતાની. તેઓ ઉદાહરણ પ્રશ્નો સમાવે છે. ત્યાં શ્રેણીમાંથી પસંદ કરેલ* તરફથી કોઈ પ્રશ્નો નથી. રસપ્રદ ફંક્શન્સનો ઉપયોગ કરીને જોડાઓ સાથે પહેલેથી જ તૈયાર ક્વેરીઝ છે જે તમને કાચા નંબરોને વાંચી શકાય તેવા, અનુકૂળ મૂલ્યોમાં ફેરવવાની મંજૂરી આપે છે, એટલે કે આ બાઇટ્સ, સમય છે. તમે તેમને પસંદ કરી શકો છો, તેમને જોઈ શકો છો, તેમનું વિશ્લેષણ કરી શકો છો, તેમને તમારા મોનિટરિંગમાં ઉમેરી શકો છો, તેમના આધારે તમારું મોનિટરિંગ બનાવી શકો છો.

પ્રશ્નો

પ્રશ્ન: તમે કહ્યું હતું કે તમે બ્રાન્ડ્સની જાહેરાત કરશો નહીં, પરંતુ હું હજી પણ ઉત્સુક છું - તમે તમારા પ્રોજેક્ટ્સમાં કયા પ્રકારનાં ડેશબોર્ડ્સનો ઉપયોગ કરો છો?
જવાબ: તે બદલાય છે. એવું બને છે કે અમે ગ્રાહક પાસે આવીએ છીએ અને તેની પાસે પહેલેથી જ તેનું પોતાનું મોનિટરિંગ છે. અને અમે ગ્રાહકને સલાહ આપીએ છીએ કે તેમના મોનિટરિંગમાં શું ઉમેરવાની જરૂર છે. સૌથી ખરાબ પરિસ્થિતિ ઝબ્બીક્સની છે. કારણ કે તેમાં ટોપએન ગ્રાફ બનાવવાની ક્ષમતા નથી. આપણે પોતે ઉપયોગ કરીએ છીએ ઓકમીટરકારણ કે અમે મોનિટરિંગ પર આ શખ્સની સલાહ લીધી હતી. તેઓએ અમારા TORના આધારે PostgreSQL મોનિટરિંગ કર્યું. હું મારો પોતાનો પેટ-પ્રોજેક્ટ લખી રહ્યો છું, જે પ્રોમિથિયસ દ્વારા ડેટા એકત્રિત કરે છે અને તેને અંદર ખેંચે છે ગ્રાફના. મારું કાર્ય પ્રોમિથિયસમાં મારા પોતાના નિકાસકાર બનાવવાનું છે અને પછી ગ્રાફનામાં બધું રેન્ડર કરવાનું છે.

પ્રશ્ન: શું AWR રિપોર્ટ્સ અથવા... એકત્રીકરણના કોઈ એનાલોગ છે? શું તમે આવા કંઈક વિશે જાણો છો?
જવાબ: હા, મને ખબર છે કે AWR શું છે, તે એક સરસ વાત છે. આ ક્ષણે ત્યાં વિવિધ પ્રકારની સાયકલ છે જે લગભગ નીચેના મોડેલને અમલમાં મૂકે છે. અમુક સમયાંતરે, અમુક આધારરેખાઓ સમાન PostgreSQL અથવા અલગ સ્ટોરેજ પર લખવામાં આવે છે. તમે તેમને ઇન્ટરનેટ પર ગૂગલ કરી શકો છો, તેઓ ત્યાં છે. આવી વસ્તુના વિકાસકર્તાઓમાંનો એક પોસ્ટગ્રેએસક્યુએલ થ્રેડમાં sql.ru ફોરમ પર બેઠો છે. તમે તેને ત્યાં પકડી શકો છો. હા, આવી વસ્તુઓ છે, તેનો ઉપયોગ કરી શકાય છે. પ્લસ તેના માં pgCenter હું એક એવી વસ્તુ પણ લખી રહ્યો છું જે તમને તે જ વસ્તુ કરવા દે છે.

PS1 જો તમે postgres_exporter નો ઉપયોગ કરી રહ્યા છો, તો તમે કયા ડેશબોર્ડનો ઉપયોગ કરો છો? તેમાંના ઘણા છે. તેઓ પહેલેથી જ જૂના છે. કદાચ સમુદાય અપડેટેડ ટેમ્પલેટ બનાવશે?

PS2 દૂર કરેલ pganalize કારણ કે તે માલિકીની SaaS ઓફર છે જે પ્રદર્શન મોનીટરીંગ અને સ્વચાલિત ટ્યુનિંગ સૂચનો પર ધ્યાન કેન્દ્રિત કરે છે.

ફક્ત નોંધાયેલા વપરાશકર્તાઓ જ સર્વેમાં ભાગ લઈ શકે છે. સાઇન ઇન કરો, મહેરબાની કરીને.

તમે કયું સ્વ-હોસ્ટેડ પોસ્ટગ્રેસ્કલ મોનિટરિંગ (ડૅશબોર્ડ સાથે) શ્રેષ્ઠ માનો છો?

• 30,0%Zabbix + Alexey Lesovsky અથવા zabbix 4.4 અથવા libzbxpgsql + zabbix libzbxpgsql + zabbix3 ના ઉમેરાઓ

• 0,0%https://github.com/lesovsky/pgcenter0

• 0,0%https://github.com/pg-monz/pg_monz0

• 20,0%https://github.com/cybertec-postgresql/pgwatch22

• 20,0%https://github.com/postgrespro/mamonsu2

• 0,0%https://www.percona.com/doc/percona-monitoring-and-management/conf-postgres.html0

• 10,0%pganalize એ માલિકીનું SaaS છે - હું તેને કાઢી શકતો નથી1

• 10,0%https://github.com/powa-team/powa1

• 0,0%https://github.com/darold/pgbadger0

• 0,0%https://github.com/darold/pgcluu0

• 0,0%https://github.com/zalando/PGObserver0

• 10,0%https://github.com/spotify/postgresql-metrics1

10 વપરાશકર્તાઓએ મતદાન કર્યું. 26 વપરાશકર્તાઓ દૂર રહ્યા.

સોર્સ: www.habr.com