ພື້ນຖານຂອງການຕິດຕາມ PostgreSQL. Alexey Lesovsky

ຂ້າພະເຈົ້າແນະນໍາໃຫ້ທ່ານອ່ານບົດບັນທຶກຂອງບົດລາຍງານໂດຍ Alexey Lesovsky ຈາກ Data Egret "ພື້ນຖານຂອງການຕິດຕາມ PostgreSQL"

ໃນບົດລາຍງານນີ້, Alexey Lesovsky ຈະເວົ້າກ່ຽວກັບຈຸດສໍາຄັນຂອງສະຖິຕິ post-gress, ສິ່ງທີ່ພວກເຂົາຫມາຍຄວາມວ່າ, ແລະເປັນຫຍັງພວກເຂົາຄວນຈະມີຢູ່ໃນການຕິດຕາມ; ກ່ຽວກັບສິ່ງທີ່ກາຟຄວນຈະຢູ່ໃນການຕິດຕາມ, ວິທີການເພີ່ມພວກມັນແລະວິທີການຕີຄວາມມັນ. ບົດລາຍງານຈະເປັນປະໂຫຍດຕໍ່ຜູ້ບໍລິຫານຖານຂໍ້ມູນ, ຜູ້ບໍລິຫານລະບົບແລະຜູ້ພັດທະນາທີ່ມີຄວາມສົນໃຈໃນການແກ້ໄຂບັນຫາ Postgres.

ຂ້ອຍຊື່ Alexey Lesovsky, ຂ້ອຍເປັນຕົວແທນຂອງບໍລິສັດ Data Egret.

ສອງສາມຄໍາກ່ຽວກັບຕົວຂ້ອຍເອງ. ຂ້າພະເຈົ້າໄດ້ເລີ່ມຕົ້ນເປັນເວລາດົນນານກ່ອນຫນ້ານີ້ເປັນຜູ້ເບິ່ງແຍງລະບົບ.

ຂ້າພະເຈົ້າໄດ້ຄຸ້ມຄອງລະບົບ Linux ຕ່າງໆທີ່ແຕກຕ່າງກັນ, ເຮັດວຽກກ່ຽວກັບສິ່ງຕ່າງໆທີ່ກ່ຽວຂ້ອງກັບ Linux, i.e. virtualization, ການຕິດຕາມ, ເຮັດວຽກກັບ proxies, ແລະອື່ນໆ. ແຕ່ໃນບາງຈຸດຂ້ອຍເລີ່ມເຮັດວຽກກັບຖານຂໍ້ມູນ, PostgreSQL. ຂ້ອຍມັກລາວແທ້ໆ. ແລະໃນບາງຈຸດຂ້າພະເຈົ້າໄດ້ເລີ່ມເຮັດວຽກກ່ຽວກັບ PostgreSQL ເກືອບທັງຫມົດທີ່ໃຊ້ເວລາເຮັດວຽກຂອງຂ້າພະເຈົ້າ. ແລະດັ່ງນັ້ນຄ່ອຍໆຂ້ອຍກາຍເປັນ PostgreSQL DBA.

ແລະຕະຫຼອດການເຮັດວຽກຂອງຂ້າພະເຈົ້າ, ຂ້າພະເຈົ້າສະເຫມີມີຄວາມສົນໃຈໃນຫົວຂໍ້ຂອງສະຖິຕິ, ການຕິດຕາມ, ແລະ telemetry. ແລະໃນເວລາທີ່ຂ້າພະເຈົ້າເປັນຜູ້ເບິ່ງແຍງລະບົບ, ຂ້າພະເຈົ້າໄດ້ເຮັດວຽກຢ່າງໃກ້ຊິດກັບ Zabbix. ແລະຂ້າພະເຈົ້າໄດ້ຂຽນຊຸດນ້ອຍໆຂອງສະຄິບເຊັ່ນ zabbix-extensions. ລາວເປັນທີ່ນິຍົມຫຼາຍໃນເວລາຂອງລາວ. ແລະຢູ່ທີ່ນັ້ນມັນເປັນໄປໄດ້ທີ່ຈະຕິດຕາມສິ່ງທີ່ສໍາຄັນທີ່ແຕກຕ່າງກັນຫຼາຍ, ບໍ່ພຽງແຕ່ Linux, ແຕ່ຍັງອົງປະກອບຕ່າງໆ.

ຕອນນີ້ຂ້ອຍກໍາລັງເຮັດວຽກກ່ຽວກັບ PostgreSQL. ຂ້ອຍກໍາລັງຂຽນສິ່ງອື່ນທີ່ອະນຸຍາດໃຫ້ທ່ານເຮັດວຽກກັບສະຖິຕິ PostgreSQL. ມັນ​ຖືກ​ເອີ້ນ​ວ່າ pgCenter (ບົດຄວາມກ່ຽວກັບ Habre - ສະຖິຕິ Post-gress ໂດຍບໍ່ມີເສັ້ນປະສາດແລະຄວາມເຄັ່ງຕຶງ).

ຂໍ້ແນະນໍາເລັກນ້ອຍ. ລູກຄ້າຂອງພວກເຮົາ, ລູກຄ້າຂອງພວກເຮົາມີສະຖານະການແນວໃດ? ມີບາງປະເພດຂອງອຸປະຕິເຫດທີ່ກ່ຽວຂ້ອງກັບຖານຂໍ້ມູນ. ແລະເມື່ອຖານຂໍ້ມູນໄດ້ຖືກຟື້ນຟູແລ້ວ, ຫົວໜ້າພະແນກຫຼືຫົວຫນ້າການພັດທະນາກໍ່ມາແລະເວົ້າວ່າ: "ເພື່ອນ, ພວກເຮົາຈໍາເປັນຕ້ອງຕິດຕາມຖານຂໍ້ມູນ, ເພາະວ່າມີບາງສິ່ງບາງຢ່າງທີ່ບໍ່ດີແລະພວກເຮົາຈໍາເປັນຕ້ອງປ້ອງກັນບໍ່ໃຫ້ມັນເກີດຂຶ້ນໃນອະນາຄົດ." ແລະໃນທີ່ນີ້ເລີ່ມຕົ້ນຂະບວນການທີ່ຫນ້າສົນໃຈຂອງການເລືອກລະບົບການຕິດຕາມຫຼືການປັບຕົວລະບົບການຕິດຕາມທີ່ມີຢູ່ເພື່ອໃຫ້ທ່ານສາມາດກວດສອບຖານຂໍ້ມູນຂອງທ່ານ - PostgreSQL, MySQL ຫຼືບາງອັນອື່ນໆ. ແລະເພື່ອນຮ່ວມງານເລີ່ມຕົ້ນແນະນໍາ: "ຂ້ອຍໄດ້ຍິນວ່າມີຖານຂໍ້ມູນດັ່ງກ່າວແລະແບບນັ້ນ. ໃຫ້ໃຊ້ມັນ." ເພື່ອນຮ່ວມງານເລີ່ມໂຕ້ຖຽງກັນ. ແລະໃນທີ່ສຸດມັນປາກົດວ່າພວກເຮົາເລືອກເອົາບາງປະເພດຂອງຖານຂໍ້ມູນ, ແຕ່ການກວດສອບ PostgreSQL ໄດ້ຖືກນໍາສະເຫນີຢູ່ໃນມັນບໍ່ດີແລະພວກເຮົາສະເຫມີຕ້ອງເພີ່ມບາງສິ່ງບາງຢ່າງ. ເອົາບາງ repositories ຈາກ GitHub, clone ໃຫ້ເຂົາເຈົ້າ, ປັບ scripts, ແລະ somehow ປັບໃຫ້ເຂົາເຈົ້າ. ແລະໃນທີ່ສຸດມັນສິ້ນສຸດລົງເຖິງບາງປະເພດຂອງການເຮັດວຽກຄູ່ມື.

ດັ່ງນັ້ນ, ໃນການສົນທະນານີ້ຂ້າພະເຈົ້າຈະພະຍາຍາມໃຫ້ທ່ານມີຄວາມຮູ້ບາງຢ່າງກ່ຽວກັບວິທີການເລືອກການຕິດຕາມບໍ່ພຽງແຕ່ສໍາລັບ PostgreSQL, ແຕ່ຍັງສໍາລັບຖານຂໍ້ມູນ. ແລະໃຫ້ຄວາມຮູ້ທີ່ຈະຊ່ວຍໃຫ້ທ່ານເຮັດສໍາເລັດການຕິດຕາມຂອງທ່ານເພື່ອໃຫ້ໄດ້ຮັບຜົນປະໂຫຍດບາງຢ່າງຈາກມັນ, ດັ່ງນັ້ນທ່ານສາມາດຕິດຕາມກວດກາຖານຂໍ້ມູນຂອງທ່ານດ້ວຍຜົນປະໂຫຍດ, ເພື່ອປ້ອງກັນສະຖານະການສຸກເສີນທີ່ອາດຈະເກີດຂື້ນໃນທັນທີ.

ແລະແນວຄວາມຄິດທີ່ຈະຢູ່ໃນບົດລາຍງານນີ້ສາມາດຖືກດັດແປງໂດຍກົງກັບຖານຂໍ້ມູນໃດກໍ່ຕາມ, ບໍ່ວ່າຈະເປັນ DBMS ຫຼື noSQL. ດັ່ງນັ້ນ, ບໍ່ພຽງແຕ່ PostgreSQL ເທົ່ານັ້ນ, ແຕ່ຈະມີສູດສູດຫຼາຍຢ່າງກ່ຽວກັບວິທີເຮັດສິ່ງນີ້ໃນ PostgreSQL. ຈະມີຕົວຢ່າງຂອງການສອບຖາມ, ຕົວຢ່າງຂອງຫນ່ວຍງານທີ່ PostgreSQL ມີສໍາລັບການຕິດຕາມ. ແລະຖ້າ DBMS ຂອງທ່ານມີສິ່ງດຽວກັນທີ່ຊ່ວຍໃຫ້ທ່ານສາມາດໃສ່ພວກມັນໃນການຕິດຕາມ, ທ່ານຍັງສາມາດປັບພວກມັນໄດ້, ເພີ່ມພວກມັນແລະມັນຈະດີ.

ຂ້ອຍຈະບໍ່ຢູ່ໃນບົດລາຍງານ
ສົນທະນາກ່ຽວກັບວິທີການຈັດສົ່ງແລະເກັບຮັກສາ metrics. ຂ້າພະເຈົ້າຈະບໍ່ເວົ້າຫຍັງກ່ຽວກັບການຕອບການປຸງແຕ່ງຂໍ້ມູນແລະນໍາສະເຫນີໃຫ້ຜູ້ໃຊ້. ແລະຂ້ອຍຈະບໍ່ເວົ້າຫຍັງກ່ຽວກັບການເຕືອນ.
ແຕ່ໃນຂະນະທີ່ເລື່ອງກ້າວຫນ້າ, ຂ້າພະເຈົ້າຈະສະແດງໃຫ້ເຫັນພາບຫນ້າຈໍທີ່ແຕກຕ່າງກັນຂອງການຕິດຕາມທີ່ມີຢູ່ແລ້ວແລະ somehow ຕໍານິຕິຕຽນພວກເຂົາ. ແຕ່ຢ່າງໃດກໍ່ຕາມ, ຂ້າພະເຈົ້າຈະພະຍາຍາມບໍ່ຕັ້ງຊື່ຍີ່ຫໍ້ເພື່ອບໍ່ໃຫ້ສ້າງການໂຄສະນາຫຼືການໂຄສະນາຕ້ານການໂຄສະນາສໍາລັບຜະລິດຕະພັນເຫຼົ່ານີ້. ເພາະສະນັ້ນ, ຄວາມບັງເອີນທັງຫມົດແມ່ນແບບສຸ່ມແລະຖືກປະໄວ້ໃນຈິນຕະນາການຂອງເຈົ້າ.

ທໍາອິດ, ໃຫ້ເຮົາຄິດອອກວ່າການຕິດຕາມແມ່ນຫຍັງ. ການຕິດຕາມເປັນສິ່ງທີ່ສໍາຄັນຫຼາຍທີ່ຈະມີ. ທຸກຄົນເຂົ້າໃຈເລື່ອງນີ້. ແຕ່ໃນເວລາດຽວກັນ, ການຕິດຕາມບໍ່ກ່ຽວຂ້ອງກັບຜະລິດຕະພັນຂອງທຸລະກິດແລະບໍ່ມີຜົນກະທົບໂດຍກົງຕໍ່ຜົນກໍາໄລຂອງບໍລິສັດ, ດັ່ງນັ້ນເວລາແມ່ນຖືກຈັດສັນສະເຫມີເພື່ອຕິດຕາມກວດກາບົນພື້ນຖານການຕົກຄ້າງ. ຖ້າພວກເຮົາມີເວລາ, ພວກເຮົາຕິດຕາມ; ຖ້າພວກເຮົາບໍ່ມີເວລາ, ຕົກລົງ, ພວກເຮົາຈະເອົາມັນໄວ້ໃນບັນທຶກແລະມື້ຫນຶ່ງພວກເຮົາຈະກັບຄືນສູ່ວຽກງານເຫຼົ່ານີ້.

ດັ່ງນັ້ນ, ຈາກການປະຕິບັດຂອງພວກເຮົາ, ເມື່ອພວກເຮົາໄປຫາລູກຄ້າ, ການຕິດຕາມມັກຈະບໍ່ຄົບຖ້ວນແລະບໍ່ມີສິ່ງທີ່ຫນ້າສົນໃຈທີ່ຈະຊ່ວຍໃຫ້ພວກເຮົາເຮັດວຽກທີ່ດີກວ່າກັບຖານຂໍ້ມູນ. ແລະດັ່ງນັ້ນ, ການຕິດຕາມສະເຫມີຕ້ອງໄດ້ຮັບການສໍາເລັດ.

ຖານຂໍ້ມູນແມ່ນສິ່ງສະລັບສັບຊ້ອນທີ່ຍັງຕ້ອງໄດ້ຮັບການຕິດຕາມ, ເພາະວ່າຖານຂໍ້ມູນເປັນບ່ອນເກັບຂໍ້ມູນ. ແລະຂໍ້ມູນແມ່ນມີຄວາມສໍາຄັນຫຼາຍສໍາລັບບໍລິສັດ; ມັນບໍ່ສາມາດສູນເສຍໄປໃນທາງໃດກໍ່ຕາມ. ແຕ່ໃນເວລາດຽວກັນ, ຖານຂໍ້ມູນແມ່ນຊິ້ນສ່ວນຂອງຊອບແວທີ່ສັບສົນຫຼາຍ. ພວກເຂົາເຈົ້າປະກອບດ້ວຍຈໍານວນຂະຫນາດໃຫຍ່ຂອງອົງປະກອບ. ແລະຫຼາຍອົງປະກອບເຫຼົ່ານີ້ຕ້ອງໄດ້ຮັບການຕິດຕາມ.

ຖ້າພວກເຮົາກໍາລັງລົມກັນໂດຍສະເພາະກ່ຽວກັບ PostgreSQL, ຫຼັງຈາກນັ້ນ, ມັນສາມາດຖືກສະແດງຢູ່ໃນຮູບແບບຂອງໂຄງການທີ່ປະກອບດ້ວຍອົງປະກອບຈໍານວນຫລາຍ. ອົງປະກອບເຫຼົ່ານີ້ພົວພັນກັບກັນແລະກັນ. ແລະໃນເວລາດຽວກັນ, PostgreSQL ມີລະບົບຍ່ອຍທີ່ເອີ້ນວ່າ Stats Collector, ເຊິ່ງຊ່ວຍໃຫ້ທ່ານສາມາດເກັບກໍາສະຖິຕິກ່ຽວກັບການດໍາເນີນງານຂອງລະບົບຍ່ອຍເຫຼົ່ານີ້ແລະສະຫນອງປະເພດຂອງການໂຕ້ຕອບກັບຜູ້ບໍລິຫານຫຼືຜູ້ໃຊ້ເພື່ອໃຫ້ລາວສາມາດເບິ່ງສະຖິຕິເຫຼົ່ານີ້.

ສະຖິຕິເຫຼົ່ານີ້ຖືກນໍາສະເຫນີໃນຮູບແບບຂອງຫນ້າທີ່ແລະທັດສະນະທີ່ແນ່ນອນ. ພວກເຂົາຍັງສາມາດເອີ້ນວ່າຕາຕະລາງ. ນັ້ນແມ່ນ, ການນໍາໃຊ້ລູກຄ້າ psql ປົກກະຕິ, ທ່ານສາມາດເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ເລືອກເອົາຫນ້າທີ່ແລະມຸມເບິ່ງເຫຼົ່ານີ້, ແລະໄດ້ຮັບຕົວເລກສະເພາະກ່ຽວກັບການປະຕິບັດງານຂອງລະບົບຍ່ອຍ PostgreSQL.

ທ່ານສາມາດເພີ່ມຕົວເລກເຫຼົ່ານີ້ເຂົ້າໃນລະບົບການຕິດຕາມທີ່ທ່ານມັກ, ແຕ້ມກາຟ, ເພີ່ມຫນ້າທີ່ແລະໄດ້ຮັບການວິເຄາະໃນໄລຍະຍາວ.

ແຕ່ໃນບົດລາຍງານນີ້ຂ້ອຍຈະບໍ່ກວມເອົາຫນ້າທີ່ທັງຫມົດເຫຼົ່ານີ້ຢ່າງສົມບູນ, ເພາະວ່າມັນສາມາດໃຊ້ເວລາຫມົດມື້. ຂ້າ​ພະ​ເຈົ້າ​ຈະ​ຮູ້​ຈັກ​ສອງ, ສາມ​ຫຼື​ສີ່​ສິ່ງ​ທີ່​ຮູ້​ຫນັງ​ສື​ແລະ​ບອກ​ທ່ານ​ວິ​ທີ​ການ​ທີ່​ເຂົາ​ເຈົ້າ​ຊ່ວຍ​ເຮັດ​ໃຫ້​ການ​ຕິດ​ຕາມ​ກວດ​ກາ​ດີກ​ວ່າ.

ແລະຖ້າພວກເຮົາສົນທະນາກ່ຽວກັບການກວດສອບຖານຂໍ້ມູນ, ແລ້ວສິ່ງທີ່ຕ້ອງຕິດຕາມ? ກ່ອນອື່ນ ໝົດ, ພວກເຮົາຕ້ອງຕິດຕາມກວດກາຄວາມພ້ອມ, ເພາະວ່າຖານຂໍ້ມູນແມ່ນການບໍລິການທີ່ສະຫນອງການເຂົ້າເຖິງຂໍ້ມູນໃຫ້ແກ່ລູກຄ້າແລະພວກເຮົາຈໍາເປັນຕ້ອງຕິດຕາມຄວາມພ້ອມ, ແລະຍັງສະຫນອງບາງລັກສະນະທີ່ມີຄຸນນະພາບແລະປະລິມານຂອງມັນ.

ພວກເຮົາຍັງຕ້ອງການຕິດຕາມກວດກາລູກຄ້າທີ່ເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນຂອງພວກເຮົາ, ເພາະວ່າພວກເຂົາສາມາດເປັນທັງລູກຄ້າປົກກະຕິແລະລູກຄ້າທີ່ເປັນອັນຕະລາຍທີ່ສາມາດເປັນອັນຕະລາຍຕໍ່ຖານຂໍ້ມູນ. ພວກເຂົາຍັງຕ້ອງໄດ້ຮັບການຕິດຕາມແລະກິດຈະກໍາຂອງເຂົາເຈົ້າ.

ເມື່ອລູກຄ້າເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ມັນເຫັນໄດ້ຊັດເຈນວ່າພວກເຂົາເລີ່ມເຮັດວຽກກັບຂໍ້ມູນຂອງພວກເຮົາ, ດັ່ງນັ້ນພວກເຮົາຈໍາເປັນຕ້ອງຕິດຕາມວິທີການລູກຄ້າເຮັດວຽກກັບຂໍ້ມູນ: ຕາຕະລາງໃດ, ແລະໃນຂອບເຂດຫນ້ອຍ, ມີດັດຊະນີໃດ. ນັ້ນແມ່ນ, ພວກເຮົາຈໍາເປັນຕ້ອງປະເມີນວຽກງານທີ່ສ້າງຂື້ນໂດຍລູກຄ້າຂອງພວກເຮົາ.

ແຕ່, ແນ່ນອນ, ວຽກງານຍັງປະກອບດ້ວຍການຮ້ອງຂໍ. ແອັບພລິເຄຊັນເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ເຂົ້າເຖິງຂໍ້ມູນໂດຍໃຊ້ແບບສອບຖາມ, ສະນັ້ນມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະເມີນສິ່ງທີ່ສອບຖາມທີ່ພວກເຮົາມີຢູ່ໃນຖານຂໍ້ມູນ, ຕິດຕາມຄວາມພຽງພໍຂອງພວກເຂົາ, ວ່າພວກເຂົາບໍ່ໄດ້ຂຽນແບບໂກງ, ບາງທາງເລືອກຕ້ອງໄດ້ຮັບການຂຽນຄືນໃຫມ່ແລະເຮັດໃຫ້ພວກເຂົາເຮັດວຽກໄວຂຶ້ນ. ແລະມີການປະຕິບັດທີ່ດີກວ່າ.

ແລະນັບຕັ້ງແຕ່ພວກເຮົາກໍາລັງເວົ້າກ່ຽວກັບຖານຂໍ້ມູນ, ຖານຂໍ້ມູນແມ່ນຂະບວນການພື້ນຖານສະເຫມີ. ຂະບວນການພື້ນຖານຊ່ວຍຮັກສາການປະຕິບັດຖານຂໍ້ມູນໃນລະດັບທີ່ດີ, ດັ່ງນັ້ນພວກເຂົາຕ້ອງການຊັບພະຍາກອນຈໍານວນຫນຶ່ງສໍາລັບຕົນເອງເພື່ອດໍາເນີນການ. ແລະໃນເວລາດຽວກັນ, ພວກເຂົາສາມາດທັບຊ້ອນກັນກັບຊັບພະຍາກອນການຮ້ອງຂໍຂອງລູກຄ້າ, ດັ່ງນັ້ນຂະບວນການພື້ນຖານທີ່ມີຄວາມໂລບມາກສາມາດສົ່ງຜົນກະທົບຕໍ່ການປະຕິບັດການຮ້ອງຂໍຂອງລູກຄ້າໂດຍກົງ. ດັ່ງນັ້ນ, ພວກເຂົາຍັງຕ້ອງໄດ້ຮັບການຕິດຕາມແລະຕິດຕາມເພື່ອບໍ່ໃຫ້ມີການບິດເບືອນຂອງຂະບວນການພື້ນຖານ.

ແລະທັງຫມົດນີ້ໃນແງ່ຂອງການກວດສອບຖານຂໍ້ມູນຍັງຄົງຢູ່ໃນລະບົບ metric. ແຕ່ການພິຈາລະນາວ່າໂຄງສ້າງພື້ນຖານຂອງພວກເຮົາສ່ວນໃຫຍ່ຈະຍ້າຍໄປຢູ່ໃນເມຄ, ຕົວວັດແທກລະບົບຂອງເຈົ້າພາບແຕ່ລະຄົນຈະຫາຍໄປໃນພື້ນຫຼັງສະເໝີ. ແຕ່ໃນຖານຂໍ້ມູນພວກເຂົາຍັງມີຄວາມກ່ຽວຂ້ອງແລະ, ແນ່ນອນ, ມັນຍັງມີຄວາມຈໍາເປັນທີ່ຈະຕິດຕາມການວັດແທກລະບົບ.

ທຸກສິ່ງທຸກຢ່າງແມ່ນດີຫຼາຍຫຼືຫນ້ອຍກັບ metrics ລະບົບ, ທຸກລະບົບການຕິດຕາມທີ່ທັນສະໄຫມສະຫນັບສະຫນູນ metrics ເຫຼົ່ານີ້ແລ້ວ, ແຕ່ໂດຍທົ່ວໄປ, ບາງອົງປະກອບຍັງບໍ່ພຽງພໍແລະບາງສິ່ງທີ່ຕ້ອງການເພີ່ມ. ຂ້າ​ພະ​ເຈົ້າ​ຍັງ​ຈະ​ສໍາ​ຜັດ​ກັບ​ເຂົາ​ເຈົ້າ​, ຈະ​ມີ slideshow ຫຼາຍ​ກ່ຽວ​ກັບ​ພວກ​ເຂົາ​.

ຈຸດທໍາອິດຂອງແຜນການແມ່ນການເຂົ້າເຖິງ. ການເຂົ້າເຖິງແມ່ນຫຍັງ? ຄວາມພ້ອມໃນຄວາມເຂົ້າໃຈຂອງຂ້ອຍແມ່ນຄວາມສາມາດຂອງພື້ນຖານໃນການເຊື່ອມຕໍ່ການບໍລິການ, i.e. ພື້ນຖານໄດ້ຖືກຍົກຂຶ້ນມາ, ມັນເປັນການບໍລິການ, ຍອມຮັບການເຊື່ອມຕໍ່ຈາກລູກຄ້າ. ແລະການເຂົ້າຫານີ້ສາມາດຖືກປະເມີນໂດຍຄຸນລັກສະນະບາງຢ່າງ. ມັນສະດວກຫຼາຍທີ່ຈະສະແດງຄຸນລັກສະນະເຫຼົ່ານີ້ຢູ່ໃນ dashboards.

ທຸກຄົນຮູ້ວ່າ dashboards ແມ່ນຫຍັງ. ນີ້ແມ່ນເວລາທີ່ທ່ານໄດ້ເບິ່ງຫນຶ່ງຫນ້າຈໍທີ່ຂໍ້ມູນທີ່ຈໍາເປັນໄດ້ຖືກສະຫຼຸບ. ແລະທ່ານສາມາດກໍານົດທັນທີວ່າມີບັນຫາຢູ່ໃນຖານຂໍ້ມູນຫຼືບໍ່.
ດັ່ງນັ້ນ, ຄວາມພ້ອມຂອງຖານຂໍ້ມູນແລະຄຸນລັກສະນະທີ່ສໍາຄັນອື່ນໆຄວນຈະຖືກສະແດງຢູ່ໃນ dashboards ສະເຫມີເພື່ອໃຫ້ຂໍ້ມູນນີ້ຢູ່ໃນມືແລະສະເຫມີມີໃຫ້ທ່ານ. ບາງລາຍລະອຽດເພີ່ມເຕີມທີ່ຊ່ວຍໃນການສືບສວນເຫດການ, ເມື່ອສືບສວນສະຖານະການສຸກເສີນບາງຢ່າງ, ພວກມັນຈໍາເປັນຕ້ອງຖືກຈັດໃສ່ໃນ dashboards ທີສອງ, ຫຼືເຊື່ອງໄວ້ໃນການເຊື່ອມຕໍ່ drilldown ທີ່ນໍາໄປສູ່ລະບົບການຕິດຕາມຂອງພາກສ່ວນທີສາມ.

ຕົວຢ່າງຂອງລະບົບການຕິດຕາມທີ່ມີຊື່ສຽງຫນຶ່ງ. ນີ້ແມ່ນລະບົບການຕິດຕາມທີ່ເຢັນຫຼາຍ. ນາງເກັບກໍາຂໍ້ມູນຈໍານວນຫລາຍ, ແຕ່ຈາກທັດສະນະຂອງຂ້ອຍ, ນາງມີແນວຄວາມຄິດທີ່ແປກປະຫລາດຂອງ dashboards. ມີການເຊື່ອມຕໍ່ "ສ້າງ dashboard". ແຕ່ເມື່ອທ່ານສ້າງ dashboard, ທ່ານສ້າງບັນຊີລາຍຊື່ຂອງສອງຄໍລໍາ, ບັນຊີລາຍຊື່ຂອງກາຟ. ແລະໃນເວລາທີ່ທ່ານຕ້ອງການເບິ່ງບາງສິ່ງບາງຢ່າງ, ທ່ານເລີ່ມຄລິກດ້ວຍຫນູ, ເລື່ອນ, ຊອກຫາຕາຕະລາງທີ່ຕ້ອງການ. ແລະນີ້ຕ້ອງໃຊ້ເວລາ, i.e. ບໍ່ມີ dashboards ດັ່ງກ່າວ. ມີພຽງແຕ່ບັນຊີລາຍຊື່ຂອງຕາຕະລາງ.

ເຈົ້າຄວນເພີ່ມຫຍັງໃສ່ dashboards ເຫຼົ່ານີ້? ທ່ານສາມາດເລີ່ມຕົ້ນດ້ວຍລັກສະນະເຊັ່ນເວລາຕອບສະຫນອງ. PostgreSQL ມີມຸມມອງ pg_stat_statements. ມັນຖືກປິດການໃຊ້ງານໂດຍຄ່າເລີ່ມຕົ້ນ, ແຕ່ມັນເປັນຫນຶ່ງໃນມຸມເບິ່ງລະບົບທີ່ສໍາຄັນທີ່ຄວນຈະຖືກເປີດໃຊ້ແລະນໍາໃຊ້ຕະຫຼອດເວລາ. ມັນເກັບຮັກສາຂໍ້ມູນກ່ຽວກັບການສອບຖາມທັງຫມົດທີ່ດໍາເນີນການຢູ່ໃນຖານຂໍ້ມູນ.

ດັ່ງນັ້ນ, ພວກເຮົາສາມາດເລີ່ມຕົ້ນຈາກຄວາມຈິງທີ່ວ່າພວກເຮົາສາມາດໃຊ້ເວລາປະຕິບັດທັງຫມົດຂອງຄໍາຮ້ອງຂໍທັງຫມົດແລະແບ່ງມັນດ້ວຍຈໍານວນຄໍາຮ້ອງຂໍໂດຍໃຊ້ຊ່ອງຂໍ້ມູນຂ້າງເທິງ. ແຕ່ນີ້ແມ່ນອຸນຫະພູມສະເລ່ຍໃນໂຮງຫມໍ. ພວກເຮົາສາມາດເລີ່ມຕົ້ນຈາກຊ່ອງຂໍ້ມູນອື່ນໆ - ເວລາປະຕິບັດການສອບຖາມຕໍາ່ສຸດ, ສູງສຸດແລະປານກາງ. ແລະພວກເຮົາສາມາດສ້າງເປີເຊັນໄດ້; PostgreSQL ມີຫນ້າທີ່ທີ່ສອດຄ້ອງກັນສໍາລັບການນີ້. ແລະພວກເຮົາສາມາດໄດ້ຮັບຕົວເລກບາງຢ່າງທີ່ມີລັກສະນະເວລາຕອບສະຫນອງຂອງຖານຂໍ້ມູນຂອງພວກເຮົາສໍາລັບການຮ້ອງຂໍທີ່ສໍາເລັດແລ້ວ, i.e. ພວກເຮົາບໍ່ໄດ້ປະຕິບັດຄໍາຮ້ອງຂໍປອມ 'ເລືອກ 1' ແລະເບິ່ງເວລາຕອບສະຫນອງ, ແຕ່ພວກເຮົາວິເຄາະເວລາຕອບສະຫນອງສໍາລັບຄໍາຮ້ອງຂໍທີ່ສໍາເລັດແລ້ວແລະແຕ້ມ. ບໍ່ວ່າຈະເປັນຕົວເລກແຍກຕ່າງຫາກ, ຫຼືພວກເຮົາສ້າງເສັ້ນສະແດງໂດຍອີງໃສ່ມັນ.

ມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະຕິດຕາມຈໍານວນຂໍ້ຜິດພາດທີ່ເກີດຂື້ນໂດຍລະບົບໃນປະຈຸບັນ. ແລະສໍາລັບການນີ້, ທ່ານສາມາດນໍາໃຊ້ pg_stat_database view. ພວກເຮົາສຸມໃສ່ພາກສະຫນາມ xact_rollback. ພາກສະຫນາມນີ້ສະແດງໃຫ້ເຫັນບໍ່ພຽງແຕ່ຈໍານວນຂອງ rollbacks ທີ່ເກີດຂຶ້ນໃນຖານຂໍ້ມູນ, ແຕ່ຍັງໃຊ້ເວລາເຂົ້າໄປໃນບັນຊີຂອງຈໍານວນຂອງຄວາມຜິດພາດ. ເວົ້າຂ້ອນຂ້າງ, ພວກເຮົາສາມາດສະແດງຕົວເລກນີ້ຢູ່ໃນ dashboard ຂອງພວກເຮົາແລະເບິ່ງວ່າພວກເຮົາມີຂໍ້ຜິດພາດຫຼາຍປານໃດ. ຖ້າມີຄວາມຜິດພາດຫຼາຍ, ນີ້ແມ່ນເຫດຜົນທີ່ດີທີ່ຈະເບິ່ງເຂົ້າໄປໃນບັນທຶກແລະເບິ່ງວ່າພວກເຂົາມີຂໍ້ຜິດພາດປະເພດໃດແລະເປັນຫຍັງພວກມັນເກີດຂື້ນ, ແລະຫຼັງຈາກນັ້ນລົງທຶນແລະແກ້ໄຂພວກມັນ.

ທ່ານສາມາດເພີ່ມສິ່ງດັ່ງກ່າວເປັນ Tachometer. ເຫຼົ່ານີ້ແມ່ນຈໍານວນການເຮັດທຸລະກໍາຕໍ່ວິນາທີແລະຈໍານວນການຮ້ອງຂໍຕໍ່ວິນາທີ. ເວົ້າຂ້ອນຂ້າງ, ທ່ານສາມາດນໍາໃຊ້ຕົວເລກເຫຼົ່ານີ້ເປັນການປະຕິບັດໃນປະຈຸບັນຂອງຖານຂໍ້ມູນຂອງທ່ານແລະສັງເກດເຫັນວ່າມີຈຸດສູງສຸດໃນການຮ້ອງຂໍ, ສູງສຸດໃນການເຮັດທຸລະກໍາ, ຫຼືໃນທາງກັບກັນ, ຖານຂໍ້ມູນແມ່ນ underloaded ເນື່ອງຈາກວ່າ backend ບາງຢ່າງລົ້ມເຫລວ. ມັນເປັນສິ່ງ ສຳ ຄັນທີ່ຈະຕ້ອງເບິ່ງຕົວເລກນີ້ຢູ່ສະ ເໝີ ແລະຈື່ໄວ້ວ່າ ສຳ ລັບໂຄງການຂອງພວກເຮົາ ການປະຕິບັດແບບນີ້ເປັນເລື່ອງປົກກະຕິ, ແຕ່ຄ່າຂ້າງເທິງແລະຂ້າງລຸ່ມນີ້ແມ່ນບາງປະເພດຂອງບັນຫາແລະບໍ່ສາມາດເຂົ້າໃຈໄດ້, ຊຶ່ງຫມາຍຄວາມວ່າພວກເຮົາຕ້ອງເບິ່ງວ່າເປັນຫຍັງຕົວເລກເຫຼົ່ານີ້. ສູງຫຼາຍ.

ເພື່ອປະເມີນຈໍານວນການເຮັດທຸລະກໍາ, ພວກເຮົາສາມາດອ້າງອີງເຖິງ pg_stat_database view ອີກຄັ້ງ. ພວກເຮົາສາມາດເພີ່ມຈໍານວນຂອງ commits ແລະຈໍານວນຂອງ rollbacks ແລະໄດ້ຮັບຈໍານວນຂອງທຸລະກໍາຕໍ່ວິນາທີ.

ທຸກຄົນເຂົ້າໃຈວ່າການຮ້ອງຂໍຫຼາຍອັນສາມາດເຂົ້າກັບທຸລະກໍາດຽວໄດ້ບໍ? ດັ່ງນັ້ນ TPS ແລະ QPS ແມ່ນແຕກຕ່າງກັນເລັກນ້ອຍ.

ຈໍານວນຄໍາຮ້ອງຂໍຕໍ່ວິນາທີສາມາດໄດ້ຮັບຈາກ pg_stat_statements ແລະພຽງແຕ່ຄິດໄລ່ຜົນລວມຂອງຄໍາຮ້ອງຂໍທີ່ສໍາເລັດທັງຫມົດ. ມັນເປັນທີ່ຊັດເຈນວ່າພວກເຮົາປຽບທຽບມູນຄ່າໃນປະຈຸບັນກັບອັນກ່ອນຫນ້າ, ລົບມັນ, ເອົາ delta, ແລະໄດ້ຮັບປະລິມານ.

ທ່ານສາມາດເພີ່ມ metrics ເພີ່ມເຕີມໄດ້ຖ້າຕ້ອງການ, ເຊິ່ງຍັງຊ່ວຍປະເມີນຄວາມພ້ອມຂອງຖານຂໍ້ມູນຂອງພວກເຮົາແລະຕິດຕາມເບິ່ງວ່າມີການ downtime ໃດ.

ຫນຶ່ງໃນຕົວວັດແທກເຫຼົ່ານີ້ແມ່ນເວລາຫວ່າງ. ແຕ່ເວລາເຮັດວຽກໃນ PostgreSQL ແມ່ນຫຍຸ້ງຍາກເລັກນ້ອຍ. ຂ້ອຍຈະບອກເຈົ້າວ່າເປັນຫຍັງ. ເມື່ອ PostgreSQL ໄດ້ເລີ່ມຕົ້ນ, ເວລາເຮັດວຽກເລີ່ມລາຍງານ. ແຕ່ຖ້າບາງຈຸດ, ຕົວຢ່າງ, ວຽກງານບາງຢ່າງເຮັດວຽກໃນຕອນກາງຄືນ, ຜູ້ຂ້າ OOM ໄດ້ມາແລະບັງຄັບໃຫ້ຂະບວນການເດັກນ້ອຍ PostgreSQL, ຫຼັງຈາກນັ້ນ, ໃນກໍລະນີນີ້ PostgreSQL ຢຸດການເຊື່ອມຕໍ່ຂອງລູກຄ້າທັງຫມົດ, ປັບພື້ນທີ່ຫນ່ວຍຄວາມຈໍາທີ່ຖືກທໍາລາຍແລະເລີ່ມຕົ້ນການຟື້ນຕົວຈາກ. ດ່ານສຸດທ້າຍ. ແລະໃນຂະນະທີ່ການຟື້ນຕົວຈາກຈຸດກວດການີ້ແກ່ຍາວ, ຖານຂໍ້ມູນບໍ່ຍອມຮັບການເຊື່ອມຕໍ່, i.e. ສະຖານະການນີ້ສາມາດຖືກປະເມີນວ່າເປັນການຢຸດເຮັດວຽກ. ແຕ່ເຄື່ອງນັບເວລາເຮັດວຽກຈະບໍ່ຖືກຕັ້ງຄ່າໃໝ່, ເພາະວ່າມັນໃຊ້ເວລາເຂົ້າໄປໃນບັນຊີເວລາເລີ່ມຕົ້ນຂອງ postmaster ຈາກປັດຈຸບັນທໍາອິດ. ດັ່ງນັ້ນ, ສະຖານະການດັ່ງກ່າວສາມາດຂ້າມໄດ້.

ທ່ານກໍ່ຄວນຕິດຕາມຈໍານວນຂອງພະນັກງານສູນຍາກາດ. ທຸກຄົນຮູ້ວ່າ autovacuum ແມ່ນຫຍັງຢູ່ໃນ PostgreSQL? ນີ້ແມ່ນລະບົບຍ່ອຍທີ່ຫນ້າສົນໃຈໃນ PostgreSQL. ບົດຄວາມຈໍານວນຫຼາຍໄດ້ຖືກຂຽນກ່ຽວກັບນາງ, ບົດລາຍງານຈໍານວນຫຼາຍໄດ້ຖືກເຮັດ. ມີຫຼາຍການສົນທະນາກ່ຽວກັບການສູນຍາກາດແລະວິທີທີ່ມັນຄວນຈະເຮັດວຽກ. ຫຼາຍ​ຄົນ​ຖື​ວ່າ​ເປັນ​ຄວາມ​ຊົ່ວ​ຮ້າຍ​ທີ່​ຈຳ​ເປັນ. ແຕ່ນັ້ນເປັນແນວໃດ. ນີ້ແມ່ນປະເພດຂອງການປຽບທຽບຂອງເຄື່ອງເກັບຂີ້ເຫຍື້ອທີ່ເຮັດຄວາມສະອາດແຖວທີ່ລ້າສະໄຫມທີ່ບໍ່ຈໍາເປັນໂດຍການເຮັດທຸລະກໍາໃດໆແລະເພີ່ມພື້ນທີ່ຫວ່າງໃນຕາຕະລາງແລະດັດສະນີສໍາລັບແຖວໃຫມ່.

ເປັນຫຍັງທ່ານຈໍາເປັນຕ້ອງຕິດຕາມມັນ? ເນື່ອງຈາກວ່າການດູດຊືມບາງຄັ້ງກໍ່ເຈັບປວດຫຼາຍ. ມັນບໍລິໂພກຊັບພະຍາກອນຈໍານວນຫຼວງຫຼາຍແລະການຮ້ອງຂໍຂອງລູກຄ້າເລີ່ມທົນທຸກຍ້ອນຜົນ.

ແລະມັນຄວນຈະຖືກຕິດຕາມຜ່ານມຸມເບິ່ງ pg_stat_activity, ທີ່ຂ້ອຍຈະເວົ້າກ່ຽວກັບພາກຕໍ່ໄປ. ທັດສະນະນີ້ສະແດງໃຫ້ເຫັນກິດຈະກໍາໃນປະຈຸບັນໃນຖານຂໍ້ມູນ. ແລະໂດຍຜ່ານກິດຈະກໍານີ້ພວກເຮົາສາມາດຕິດຕາມຈໍານວນຂອງສູນຍາກາດທີ່ເຮັດວຽກໃນປັດຈຸບັນ. ພວກເຮົາສາມາດຕິດຕາມສູນຍາກາດແລະເບິ່ງວ່າຖ້າພວກເຮົາໄດ້ເກີນຂອບເຂດຈໍາກັດ, ນີ້ແມ່ນເຫດຜົນທີ່ຈະເບິ່ງເຂົ້າໄປໃນການຕັ້ງຄ່າ PostgreSQL ແລະວິທີການເພີ່ມປະສິດທິພາບຂອງສູນຍາກາດ.

ສິ່ງອື່ນກ່ຽວກັບ PostgreSQL ແມ່ນວ່າ PostgreSQL ເຈັບປ່ວຍຫຼາຍຂອງການເຮັດທຸລະກໍາທີ່ຍາວນານ. ໂດຍສະເພາະຈາກການເຮັດທຸລະກໍາທີ່ຫ້ອຍປະມານເປັນເວລາດົນນານແລະບໍ່ເຮັດຫຍັງເລີຍ. ນີ້ແມ່ນອັນທີ່ເອີ້ນວ່າ stat idle-in-transaction. ການເຮັດທຸລະກໍາດັ່ງກ່າວຖື locks ແລະປ້ອງກັນບໍ່ໃຫ້ສູນຍາກາດເຮັດວຽກ. ແລະດັ່ງນັ້ນ, ຕາຕະລາງຈະບວມແລະຂະຫນາດເພີ່ມຂຶ້ນ. ແລະການສອບຖາມທີ່ເຮັດວຽກກັບຕາຕະລາງເຫຼົ່ານີ້ເລີ່ມເຮັດວຽກຊ້າລົງ, ເພາະວ່າທ່ານຈໍາເປັນຕ້ອງຊ້ວນທຸກລຸ້ນເກົ່າຂອງແຖວຈາກຫນ່ວຍຄວາມຈໍາໄປຫາແຜ່ນແລະກັບຄືນໄປບ່ອນ. ດັ່ງນັ້ນ, ໄລຍະເວລາ, ໄລຍະເວລາຂອງການເຮັດທຸລະກໍາທີ່ຍາວທີ່ສຸດ, ການຮ້ອງຂໍສູນຍາກາດທີ່ຍາວທີ່ສຸດກໍ່ຕ້ອງໄດ້ຮັບການຕິດຕາມ. ແລະຖ້າພວກເຮົາເຫັນບາງຂະບວນການທີ່ເຮັດວຽກເປັນເວລາດົນນານ, ແລ້ວຫຼາຍກ່ວາ 10-20-30 ນາທີສໍາລັບການໂຫຼດ OLTP, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ເອົາໃຈໃສ່ກັບພວກເຂົາແລະບັງຄັບໃຫ້ພວກເຂົາຢຸດ, ຫຼືເພີ່ມປະສິດທິພາບຄໍາຮ້ອງສະຫມັກເພື່ອໃຫ້ພວກເຂົາ. ບໍ່​ໄດ້​ຖືກ​ເອີ້ນ​ແລະ​ບໍ່​ໄດ້​ວາງ​ສາຍ​ຍາວ​ນັ້ນ​. ສໍາລັບວຽກງານການວິເຄາະ, 10-20-30 ນາທີແມ່ນປົກກະຕິ, ຍັງມີເວລາດົນກວ່າ.

ຕໍ່ໄປພວກເຮົາມີທາງເລືອກກັບລູກຄ້າທີ່ເຊື່ອມຕໍ່. ເມື່ອພວກເຮົາໄດ້ສ້າງ dashboard ແລະປະກາດການວັດແທກຄວາມພ້ອມທີ່ສໍາຄັນຢູ່ໃນມັນ, ພວກເຮົາຍັງສາມາດເພີ່ມຂໍ້ມູນເພີ່ມເຕີມກ່ຽວກັບລູກຄ້າທີ່ເຊື່ອມຕໍ່ຢູ່ທີ່ນັ້ນ.

ຂໍ້ມູນກ່ຽວກັບລູກຄ້າທີ່ເຊື່ອມຕໍ່ແມ່ນສໍາຄັນເພາະວ່າ, ຈາກທັດສະນະຂອງ PostgreSQL, ລູກຄ້າແມ່ນແຕກຕ່າງກັນ. ມີ​ລູກ​ຄ້າ​ທີ່​ດີ ແລະ​ມີ​ລູກ​ຄ້າ​ທີ່​ບໍ່​ດີ.

ຕົວຢ່າງງ່າຍໆ. ໂດຍລູກຄ້າຂ້ອຍເຂົ້າໃຈຄໍາຮ້ອງສະຫມັກ. ຄໍາຮ້ອງສະຫມັກໄດ້ເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນແລະທັນທີເລີ່ມຕົ້ນສົ່ງຄໍາຮ້ອງຂໍຂອງຕົນຢູ່ທີ່ນັ້ນ, ຂະບວນການຖານຂໍ້ມູນແລະປະຕິບັດໃຫ້ເຂົາເຈົ້າ, ແລະສົ່ງຜົນໄດ້ຮັບກັບລູກຄ້າ. ເຫຼົ່ານີ້ແມ່ນລູກຄ້າທີ່ດີແລະຖືກຕ້ອງ.

ມີສະຖານະການໃນເວລາທີ່ລູກຄ້າໄດ້ເຊື່ອມຕໍ່, ມັນຖືການເຊື່ອມຕໍ່, ແຕ່ບໍ່ມີຫຍັງເລີຍ. ມັນຢູ່ໃນສະຖານະທີ່ບໍ່ມີປະໂຫຍດ.

ແຕ່ມີລູກຄ້າທີ່ບໍ່ດີ. ຕົວຢ່າງ, ລູກຄ້າດຽວກັນໄດ້ເຊື່ອມຕໍ່, ເປີດການເຮັດທຸລະກໍາ, ເຮັດບາງສິ່ງບາງຢ່າງໃນຖານຂໍ້ມູນແລະຫຼັງຈາກນັ້ນເຂົ້າໄປໃນລະຫັດ, ຕົວຢ່າງ, ເພື່ອເຂົ້າເຖິງແຫຼ່ງພາຍນອກຫຼືການປຸງແຕ່ງຂໍ້ມູນທີ່ໄດ້ຮັບຢູ່ທີ່ນັ້ນ. ແຕ່ລາວບໍ່ໄດ້ປິດການເຮັດທຸລະກໍາ. ແລະທຸລະກໍາ hangs ໃນຖານຂໍ້ມູນແລະຖືກຈັດຂຶ້ນໃນ lock ສຸດເສັ້ນ. ນີ້ແມ່ນສະພາບທີ່ບໍ່ດີ. ແລະຖ້າຫາກວ່າທັນທີທັນໃດຄໍາຮ້ອງສະຫມັກບາງບ່ອນພາຍໃນຕົວຂອງມັນເອງລົ້ມເຫລວໂດຍມີຂໍ້ຍົກເວັ້ນ, ຫຼັງຈາກນັ້ນການເຮັດທຸລະກໍາສາມາດເປີດຢູ່ເປັນເວລາດົນນານ. ແລະນີ້ມີຜົນກະທົບໂດຍກົງຕໍ່ການປະຕິບັດ PostgreSQL. PostgreSQL ຈະຊ້າລົງ. ດັ່ງນັ້ນ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຕິດຕາມລູກຄ້າດັ່ງກ່າວໃຫ້ທັນເວລາແລະບັງຄັບໃຫ້ຢຸດເຊົາການເຮັດວຽກຂອງພວກເຂົາ. ແລະທ່ານຕ້ອງການເພີ່ມປະສິດທິພາບຄໍາຮ້ອງສະຫມັກຂອງທ່ານເພື່ອບໍ່ໃຫ້ສະຖານະການດັ່ງກ່າວເກີດຂື້ນ.

ລູກຄ້າທີ່ບໍ່ດີອື່ນໆແມ່ນລໍຖ້າລູກຄ້າ. ແຕ່ພວກເຂົາກາຍເປັນຄົນບໍ່ດີຍ້ອນສະຖານະການ. ສໍາລັບຕົວຢ່າງ, ການເຮັດທຸລະກໍາທີ່ບໍ່ມີປະໂຫຍດງ່າຍໆ: ມັນສາມາດເປີດການເຮັດທຸລະກໍາ, ລັອກບາງສາຍ, ຫຼັງຈາກນັ້ນບາງບ່ອນໃນລະຫັດມັນຈະລົ້ມເຫລວ, ເຮັດໃຫ້ທຸລະກໍາຫ້ອຍ. ລູກຄ້າອີກຄົນຫນຶ່ງຈະມາແລະຮ້ອງຂໍຂໍ້ມູນດຽວກັນ, ແຕ່ລາວຈະພົບກັບການລັອກ, ເພາະວ່າການເຮັດທຸລະກໍາທີ່ຫ້ອຍນັ້ນມີ locks ຢູ່ບາງແຖວທີ່ຕ້ອງການ. ແລະການເຮັດທຸລະກໍາທີສອງຈະຄ້າງຢູ່ລໍຖ້າການເຮັດທຸລະກໍາທໍາອິດສໍາເລັດຫຼືບັງຄັບໃຫ້ປິດມັນໂດຍຜູ້ບໍລິຫານ. ດັ່ງນັ້ນ, ການເຮັດທຸລະກໍາທີ່ຍັງຄ້າງສາມາດສະສົມແລະຕື່ມຂໍ້ມູນໃສ່ຂອບເຂດຈໍາກັດການເຊື່ອມຕໍ່ຖານຂໍ້ມູນ. ແລະເມື່ອຂອບເຂດຈໍາກັດເຕັມ, ແອັບພລິເຄຊັນບໍ່ສາມາດເຮັດວຽກກັບຖານຂໍ້ມູນໄດ້. ນີ້ແມ່ນສະຖານະການສຸກເສີນສໍາລັບໂຄງການແລ້ວ. ດັ່ງນັ້ນ, ລູກຄ້າທີ່ບໍ່ດີຕ້ອງໄດ້ຮັບການຕິດຕາມແລະຕອບສະຫນອງໃຫ້ທັນເວລາ.

ຕົວຢ່າງອື່ນຂອງການຕິດຕາມ. ແລະມີ dashboard ທີ່ເຫມາະສົມຢູ່ທີ່ນີ້. ມີຂໍ້ມູນກ່ຽວກັບການເຊື່ອມຕໍ່ຂ້າງເທິງ. ການເຊື່ອມຕໍ່ DB - 8 ຊິ້ນ. ແລະມັນທັງຫມົດ. ພວກ​ເຮົາ​ບໍ່​ມີ​ຂໍ້​ມູນ​ກ່ຽວ​ກັບ​ການ​ທີ່​ລູກ​ຄ້າ​ມີ​ການ​ເຄື່ອນ​ໄຫວ​, ທີ່​ລູກ​ຄ້າ​ພຽງ​ແຕ່​ຢູ່​ບໍ່​ມີ​ການ​ເຮັດ​ຫຍັງ​. ບໍ່ມີຂໍ້ມູນກ່ຽວກັບການເຮັດທຸລະກໍາທີ່ຍັງຄ້າງແລະການເຊື່ອມຕໍ່ທີ່ຍັງຄ້າງ, i.e. ນີ້ແມ່ນຕົວເລກທີ່ສະແດງຈໍານວນການເຊື່ອມຕໍ່ແລະນັ້ນແມ່ນ. ແລະຫຼັງຈາກນັ້ນເດົາສໍາລັບຕົວທ່ານເອງ.

ດັ່ງນັ້ນ, ເພື່ອເພີ່ມຂໍ້ມູນນີ້ເຂົ້າໃນການຕິດຕາມ, ທ່ານຈໍາເປັນຕ້ອງໄດ້ເຂົ້າຫາລະບົບ pg_stat_activity view. ຖ້າທ່ານໃຊ້ເວລາຫຼາຍໃນ PostgreSQL, ນີ້ແມ່ນທັດສະນະທີ່ດີທີ່ຄວນຈະເປັນເພື່ອນຂອງທ່ານ, ເພາະວ່າມັນສະແດງໃຫ້ເຫັນເຖິງກິດຈະກໍາໃນປະຈຸບັນໃນ PostgreSQL, i.e. ສິ່ງທີ່ເກີດຂຶ້ນໃນມັນ. ສໍາລັບແຕ່ລະຂະບວນການມີເສັ້ນແຍກຕ່າງຫາກທີ່ສະແດງຂໍ້ມູນກ່ຽວກັບຂະບວນການນີ້: ການເຊື່ອມຕໍ່ທີ່ໂຮດແມ່ນເຮັດ, ພາຍໃຕ້ຜູ້ໃຊ້ໃດ, ພາຍໃຕ້ຊື່ໃດ, ເມື່ອທຸລະກໍາໄດ້ເລີ່ມຕົ້ນ, ຄໍາຮ້ອງຂໍໃດກໍາລັງດໍາເນີນການ, ຄໍາຮ້ອງຂໍໃດຖືກປະຕິບັດ. ແລະ, ຕາມນັ້ນ, ພວກເຮົາສາມາດປະເມີນສະຖານະຂອງລູກຄ້າໂດຍໃຊ້ພາກສະຫນາມສະຖິຕິ. ເວົ້າຂ້ອນຂ້າງ, ພວກເຮົາສາມາດຈັດກຸ່ມໂດຍພາກສະຫນາມນີ້ແລະໄດ້ຮັບສະຖິຕິເຫຼົ່ານັ້ນທີ່ມີຢູ່ໃນຖານຂໍ້ມູນແລະຈໍານວນການເຊື່ອມຕໍ່ທີ່ມີສະຖິຕິນີ້ຢູ່ໃນຖານຂໍ້ມູນ. ແລະພວກເຮົາສາມາດສົ່ງຕົວເລກທີ່ໄດ້ຮັບແລ້ວໄປຫາການຕິດຕາມຂອງພວກເຮົາແລະແຕ້ມກາຟໂດຍອີງໃສ່ພວກມັນ.
ມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະປະເມີນໄລຍະເວລາຂອງການເຮັດທຸລະກໍາ. ຂ້າພະເຈົ້າໄດ້ເວົ້າແລ້ວວ່າມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະເມີນໄລຍະເວລາຂອງການສູນຍາກາດ, ແຕ່ການເຮັດທຸລະກໍາຖືກປະເມີນໃນທາງດຽວກັນ. ມີຊ່ອງຂໍ້ມູນ xact_start ແລະ query_start. ພວກເຂົາເຈົ້າ, ເວົ້າຂ້ອນຂ້າງ, ສະແດງເວລາເລີ່ມຕົ້ນຂອງທຸລະກໍາແລະເວລາເລີ່ມຕົ້ນຂອງການຮ້ອງຂໍ. ພວກເຮົາໃຊ້ຟັງຊັນ now() ເຊິ່ງສະແດງເວລາປະຈຸບັນ, ແລະຫັກລົບການເຮັດທຸລະກໍາ ແລະເວລາຮ້ອງຂໍ. ແລະພວກເຮົາໄດ້ຮັບໄລຍະເວລາຂອງການເຮັດທຸລະກໍາ, ໄລຍະເວລາຂອງການຮ້ອງຂໍ.

ຖ້າພວກເຮົາເຫັນການເຮັດທຸລະກໍາຍາວ, ພວກເຮົາຄວນຈະເຮັດສໍາເລັດມັນແລ້ວ. ສໍາລັບການໂຫຼດ OLTP, ການເຮັດທຸລະກໍາຍາວແມ່ນແລ້ວຫຼາຍກ່ວາ 1-2-3 ນາທີ. ສໍາລັບວຽກງານ OLAP, ການເຮັດທຸລະກໍາທີ່ຍາວນານແມ່ນເປັນເລື່ອງປົກກະຕິ, ແຕ່ຖ້າພວກເຂົາໃຊ້ເວລາຫຼາຍກວ່າສອງຊົ່ວໂມງເພື່ອໃຫ້ສໍາເລັດ, ນີ້ກໍ່ເປັນສັນຍານວ່າພວກເຮົາມີຄວາມບໍ່ສະບາຍຢູ່ບ່ອນໃດບ່ອນຫນຶ່ງ.

ເມື່ອລູກຄ້າໄດ້ເຊື່ອມຕໍ່ກັບຖານຂໍ້ມູນ, ພວກເຂົາເລີ່ມເຮັດວຽກກັບຂໍ້ມູນຂອງພວກເຮົາ. ພວກເຂົາເຂົ້າເຖິງຕາຕະລາງ, ພວກເຂົາເຂົ້າເຖິງດັດສະນີເພື່ອເອົາຂໍ້ມູນຈາກຕາຕະລາງ. ແລະມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະເມີນວິທີທີ່ລູກຄ້າພົວພັນກັບຂໍ້ມູນນີ້.

ນີ້ແມ່ນສິ່ງຈໍາເປັນເພື່ອປະເມີນວຽກງານຂອງພວກເຮົາແລະເຂົ້າໃຈປະມານວ່າຕາຕະລາງໃດແມ່ນ "ຮ້ອນທີ່ສຸດ" ສໍາລັບພວກເຮົາ. ຕົວຢ່າງ, ນີ້ແມ່ນຈໍາເປັນໃນສະຖານະການທີ່ພວກເຮົາຕ້ອງການວາງຕາຕະລາງ "ຮ້ອນ" ໃນບາງປະເພດຂອງການເກັບຮັກສາ SSD ໄວ. ຕົວຢ່າງ, ຕາຕະລາງເກັບມ້ຽນບາງອັນທີ່ພວກເຮົາບໍ່ໄດ້ໃຊ້ເປັນເວລາດົນນານສາມາດຖືກຍ້າຍໄປບ່ອນເກັບມ້ຽນ "ເຢັນ" ບາງປະເພດ, ໄປຫາ SATA drives ແລະໃຫ້ພວກເຂົາອາໄສຢູ່ທີ່ນັ້ນ, ພວກມັນຈະຖືກເຂົ້າເຖິງຕາມຄວາມຕ້ອງການ.

ນີ້ຍັງເປັນປະໂຫຍດສໍາລັບການກວດສອບຄວາມຜິດປົກກະຕິຫຼັງຈາກການເປີດຕົວແລະການນໍາໃຊ້ໃດໆ. ໃຫ້ເວົ້າວ່າໂຄງການໄດ້ປ່ອຍອອກມາເມື່ອຄຸນນະສົມບັດໃຫມ່ບາງຢ່າງ. ຕົວຢ່າງ, ພວກເຮົາໄດ້ເພີ່ມຫນ້າທີ່ໃຫມ່ສໍາລັບການເຮັດວຽກກັບຖານຂໍ້ມູນ. ແລະຖ້າພວກເຮົາວາງແຜນຕາຕະລາງການນໍາໃຊ້ຕາຕະລາງ, ພວກເຮົາສາມາດກວດພົບຄວາມຜິດປົກກະຕິໃນກາຟເຫຼົ່ານີ້ໄດ້ຢ່າງງ່າຍດາຍ. ຕົວຢ່າງ, ອັບເດດການລະເບີດ ຫຼືລຶບການລະເບີດອອກ. ມັນຈະເຫັນໄດ້ຫຼາຍ.

ທ່ານຍັງສາມາດກວດພົບຄວາມຜິດປົກກະຕິໃນສະຖິຕິ "ລອຍຕົວ". ມັນຫມາຍຄວາມວ່າແນວໃດ? PostgreSQL ມີຕົວກໍານົດການສອບຖາມທີ່ເຂັ້ມແຂງແລະດີຫຼາຍ. ແລະນັກພັດທະນາໄດ້ອຸທິດເວລາຫຼາຍໃນການພັດທະນາຂອງມັນ. ລາວເຮັດວຽກແນວໃດ? ເພື່ອເຮັດໃຫ້ແຜນການທີ່ດີ, PostgreSQL ເກັບກໍາສະຖິຕິກ່ຽວກັບການແຈກຢາຍຂໍ້ມູນໃນຕາຕະລາງໃນຊ່ວງເວລາທີ່ແນ່ນອນແລະມີຄວາມຖີ່ທີ່ແນ່ນອນ. ເຫຼົ່ານີ້ແມ່ນຄ່າທົ່ວໄປທີ່ສຸດ: ຈໍານວນມູນຄ່າທີ່ເປັນເອກະລັກ, ຂໍ້ມູນກ່ຽວກັບ NULL ໃນຕາຕະລາງ, ຂໍ້ມູນຈໍານວນຫລາຍ.

ອີງຕາມສະຖິຕິເຫຼົ່ານີ້, ຜູ້ວາງແຜນກໍ່ສ້າງຄໍາຖາມຈໍານວນຫນຶ່ງ, ເລືອກອັນທີ່ດີທີ່ສຸດ, ແລະນໍາໃຊ້ແຜນການສອບຖາມນີ້ເພື່ອປະຕິບັດການສອບຖາມຕົວມັນເອງແລະສົ່ງຄືນຂໍ້ມູນ.

ແລະມັນເກີດຂື້ນວ່າສະຖິຕິ "ເລື່ອນ". ຂໍ້ມູນຄຸນນະພາບແລະປະລິມານມີການປ່ຽນແປງບາງຢ່າງໃນຕາຕະລາງ, ແຕ່ສະຖິຕິບໍ່ໄດ້ເກັບກໍາ. ແລະແຜນການທີ່ສ້າງຂຶ້ນອາດຈະບໍ່ດີທີ່ສຸດ. ແລະຖ້າແຜນການຂອງພວກເຮົາກາຍເປັນສິ່ງທີ່ດີທີ່ສຸດໂດຍອີງໃສ່ການຕິດຕາມທີ່ເກັບກໍາ, ອີງຕາມຕາຕະລາງ, ພວກເຮົາຈະສາມາດເຫັນຄວາມຜິດປົກກະຕິເຫຼົ່ານີ້. ຕົວຢ່າງ, ບາງບ່ອນຂໍ້ມູນມີການປ່ຽນແປງທີ່ມີຄຸນນະພາບແລະແທນທີ່ຈະດັດສະນີ, ລໍາດັບຜ່ານຕາຕະລາງເລີ່ມຖືກນໍາໃຊ້, i.e. ຖ້າການສອບຖາມຕ້ອງການສົ່ງຄືນພຽງແຕ່ 100 ແຖວ (ມີຂອບເຂດຈໍາກັດ 100), ຫຼັງຈາກນັ້ນການຄົ້ນຫາທີ່ສົມບູນຈະຖືກປະຕິບັດສໍາລັບການສອບຖາມນີ້. ແລະນີ້ສະເຫມີມີຜົນກະທົບທີ່ບໍ່ດີຫຼາຍຕໍ່ການປະຕິບັດ.

ແລະພວກເຮົາສາມາດເຫັນນີ້ໃນການຕິດຕາມ. ແລະແລ້ວເບິ່ງຄໍາຖາມນີ້, ດໍາເນີນການອະທິບາຍສໍາລັບມັນ, ເກັບກໍາສະຖິຕິ, ສ້າງດັດສະນີເພີ່ມເຕີມໃຫມ່. ແລະຕອບສະຫນອງຕໍ່ບັນຫານີ້ແລ້ວ. ນັ້ນແມ່ນເຫດຜົນທີ່ວ່າມັນສໍາຄັນ.

ຕົວຢ່າງອື່ນຂອງການຕິດຕາມ. ຂ້າ​ພະ​ເຈົ້າ​ຄິດ​ວ່າ​ປະ​ຊາ​ຊົນ​ຈໍາ​ນວນ​ຫຼາຍ​ໄດ້​ຮັບ​ຮູ້​ຂອງ​ເຂົາ​ເພາະ​ວ່າ​ລາວ​ເປັນ​ທີ່​ນິ​ຍົມ​ຫຼາຍ​. ໃຜໃຊ້ມັນຢູ່ໃນໂຄງການຂອງພວກເຂົາ Prometheus? ໃຜໃຊ້ຜະລິດຕະພັນນີ້ຮ່ວມກັບ Prometheus? ຄວາມຈິງແລ້ວແມ່ນວ່າໃນຄັງເກັບມ້ຽນມາດຕະຖານຂອງການຕິດຕາມນີ້ມີ dashboard ສໍາລັບການເຮັດວຽກກັບ PostgreSQL - postgres_exporter Prometheus. ແຕ່ມີລາຍລະອຽດທີ່ບໍ່ດີອັນຫນຶ່ງ.

ມີຫຼາຍເສັ້ນສະແດງ. ແລະ bytes ຖືກລະບຸວ່າເປັນຄວາມສາມັກຄີ, i.e. ມີ 5 ກຣາຟ. ເຫຼົ່າ​ນີ້​ແມ່ນ​ການ​ໃສ່​ຂໍ້​ມູນ​, ຂໍ້​ມູນ​ປັບ​ປຸງ​, ລຶບ​ຂໍ້​ມູນ​, ເອົາ​ຂໍ້​ມູນ​ແລະ​ກັບ​ຄືນ​ຂໍ້​ມູນ​. ການວັດແທກຫົວໜ່ວຍແມ່ນ bytes. ແຕ່ສິ່ງທີ່ເປັນສະຖິຕິໃນ PostgreSQL ສົ່ງຄືນຂໍ້ມູນໃນ tuple (ແຖວ). ແລະ, ຕາມຄວາມເຫມາະສົມ, ກຣາຟເຫຼົ່ານີ້ແມ່ນວິທີທີ່ດີທີ່ຈະປະເມີນຄ່າວຽກຂອງເຈົ້າຫຼາຍເທື່ອ, ສິບເທື່ອ, ເພາະວ່າ tuple ບໍ່ແມ່ນ byte, tuple ແມ່ນສາຍ, ມັນແມ່ນຫຼາຍ bytes ແລະມັນມີຄວາມຍາວຕົວແປສະເຫມີ. ນັ້ນແມ່ນ, ການຄິດໄລ່ປະລິມານວຽກໃນ bytes ໂດຍໃຊ້ tuples ແມ່ນວຽກງານທີ່ບໍ່ເປັນຈິງຫຼືມີຄວາມຫຍຸ້ງຍາກຫຼາຍ. ດັ່ງນັ້ນ, ເມື່ອທ່ານໃຊ້ dashboard ຫຼືການຕິດຕາມໃນຕົວ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະເຂົ້າໃຈວ່າມັນເຮັດວຽກຢ່າງຖືກຕ້ອງແລະສົ່ງຄືນຂໍ້ມູນທີ່ຖືກປະເມີນຢ່າງຖືກຕ້ອງ.

ວິທີການເອົາສະຖິຕິໃນຕາຕະລາງເຫຼົ່ານີ້? ສໍາລັບຈຸດປະສົງນີ້, PostgreSQL ມີທັດສະນະຂອງຄອບຄົວທີ່ແນ່ນອນ. ແລະທັດສະນະຕົ້ນຕໍແມ່ນ pg_stat_user_tables. User_tables - ນີ້ຫມາຍຄວາມວ່າຕາຕະລາງທີ່ສ້າງຂຶ້ນໃນນາມຂອງຜູ້ໃຊ້. ໃນທາງກົງກັນຂ້າມ, ມີທັດສະນະຂອງລະບົບທີ່ຖືກນໍາໃຊ້ໂດຍ PostgreSQL ຕົວຂອງມັນເອງ. ແລະມີຕາຕະລາງສະຫຼຸບ Alltables, ເຊິ່ງລວມມີທັງລະບົບແລະຜູ້ໃຊ້. ເຈົ້າສາມາດເລີ່ມຈາກອັນໃດອັນໜຶ່ງທີ່ເຈົ້າມັກທີ່ສຸດ.

ການນໍາໃຊ້ຊ່ອງຂໍ້ມູນຂ້າງເທິງທ່ານສາມາດຄາດຄະເນຈໍານວນຂອງການໃສ່, ການປັບປຸງແລະການລຶບ. ຕົວຢ່າງຂອງ dashboard ທີ່ຂ້ອຍໃຊ້ໃຊ້ພາກສະຫນາມເຫຼົ່ານີ້ເພື່ອປະເມີນຄຸນລັກສະນະຂອງວຽກ. ເພາະສະນັ້ນ, ພວກເຮົາຍັງສາມາດສ້າງໃຫ້ເຂົາເຈົ້າ. ແຕ່ມັນຄຸ້ມຄ່າທີ່ຈະຈື່ໄວ້ວ່າເຫຼົ່ານີ້ແມ່ນ tuples, ບໍ່ແມ່ນ bytes, ດັ່ງນັ້ນພວກເຮົາບໍ່ສາມາດເຮັດມັນໄດ້ໃນ bytes.

ອີງຕາມຂໍ້ມູນນີ້, ພວກເຮົາສາມາດສ້າງອັນທີ່ເອີ້ນວ່າຕາຕະລາງ TopN. ຕົວຢ່າງ, Top-5, Top-10. ແລະທ່ານສາມາດຕິດຕາມຕາຕະລາງຮ້ອນເຫຼົ່ານັ້ນທີ່ຖືກນໍາມາໃຊ້ໃຫມ່ຫຼາຍກ່ວາຄົນອື່ນ. ຕົວຢ່າງ, 5 ຕາຕະລາງ "ຮ້ອນ" ສໍາລັບການແຊກ. ແລະການນໍາໃຊ້ຕາຕະລາງ TopN ເຫຼົ່ານີ້ພວກເຮົາປະເມີນວຽກງານຂອງພວກເຮົາແລະສາມາດປະເມີນການລະເບີດຂອງວຽກຫຼັງຈາກການປ່ອຍ, ການປັບປຸງ, ແລະການນໍາໃຊ້.

ມັນຍັງມີຄວາມສໍາຄັນທີ່ຈະປະເມີນຂະຫນາດຂອງຕາຕະລາງ, ເພາະວ່າບາງຄັ້ງນັກພັດທະນາໄດ້ເປີດຕົວລັກສະນະໃຫມ່, ແລະຕາຕະລາງຂອງພວກເຮົາເລີ່ມມີອາການບວມໃນຂະຫນາດໃຫຍ່, ເພາະວ່າພວກເຂົາຕັດສິນໃຈເພີ່ມຈໍານວນຂໍ້ມູນເພີ່ມເຕີມ, ແຕ່ບໍ່ໄດ້ຄາດຄະເນວ່າມັນຈະເປັນແນວໃດ. ຜົນກະທົບຕໍ່ຂະຫນາດຂອງຖານຂໍ້ມູນ. ກໍລະນີດັ່ງກ່າວຍັງເຮັດໃຫ້ພວກເຮົາແປກໃຈ.

ແລະໃນປັດຈຸບັນເປັນຄໍາຖາມຂະຫນາດນ້ອຍສໍາລັບທ່ານ. ຄໍາຖາມໃດທີ່ເກີດຂື້ນໃນເວລາທີ່ທ່ານສັງເກດເຫັນການໂຫຼດຢູ່ໃນເຄື່ອງແມ່ຂ່າຍຖານຂໍ້ມູນຂອງທ່ານ? ຄຳຖາມຕໍ່ໄປເຈົ້າມີຫຍັງ?

ແຕ່​ໃນ​ຄວາມ​ເປັນ​ຈິງ​ຄໍາ​ຖາມ​ທີ່​ເກີດ​ຂຶ້ນ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​. ການຮ້ອງຂໍການໂຫຼດແມ່ນຫຍັງ? ນັ້ນແມ່ນ, ມັນບໍ່ຫນ້າສົນໃຈທີ່ຈະເບິ່ງຂະບວນການທີ່ເກີດຈາກການໂຫຼດ. ມັນເປັນທີ່ຊັດເຈນວ່າຖ້າໂຮດມີຖານຂໍ້ມູນ, ຫຼັງຈາກນັ້ນຖານຂໍ້ມູນແມ່ນແລ່ນຢູ່ທີ່ນັ້ນແລະມັນເປັນທີ່ຊັດເຈນວ່າພຽງແຕ່ຖານຂໍ້ມູນຈະຖືກກໍາຈັດຢູ່ທີ່ນັ້ນ. ຖ້າພວກເຮົາເປີດ Top, ພວກເຮົາຈະເຫັນບັນຊີລາຍຊື່ຂອງຂະບວນການໃນ PostgreSQL ທີ່ກໍາລັງເຮັດບາງສິ່ງບາງຢ່າງ. ມັນຈະບໍ່ຈະແຈ້ງຈາກທາງເທິງວ່າພວກເຂົາເຮັດຫຍັງຢູ່.

ດັ່ງນັ້ນ, ທ່ານຈໍາເປັນຕ້ອງຊອກຫາຄໍາຖາມເຫຼົ່ານັ້ນທີ່ເຮັດໃຫ້ການໂຫຼດສູງສຸດ, ເນື່ອງຈາກວ່າການສອບຖາມ tuning, ຕາມກົດລະບຽບ, ໃຫ້ກໍາໄລຫຼາຍກ່ວາການປັບແຕ່ງ PostgreSQL ຫຼືການຕັ້ງຄ່າລະບົບປະຕິບັດງານ, ຫຼືແມ້ກະທັ້ງການປັບແຕ່ງຮາດແວ. ອີງຕາມການຄາດຄະເນຂອງຂ້ອຍ, ນີ້ແມ່ນປະມານ 80-85-90%. ແລະນີ້ແມ່ນເຮັດໄດ້ໄວຂຶ້ນຫຼາຍ. ມັນໄວກວ່າທີ່ຈະແກ້ໄຂຄໍາຮ້ອງຂໍກ່ວາການແກ້ໄຂການຕັ້ງຄ່າ, ກໍານົດເວລາການເລີ່ມຕົ້ນໃຫມ່, ໂດຍສະເພາະຖ້າຖານຂໍ້ມູນບໍ່ສາມາດເລີ່ມຕົ້ນໃຫມ່, ຫຼືເພີ່ມຮາດແວ. ມັນງ່າຍກວ່າທີ່ຈະຂຽນຄໍາຖາມຢູ່ບ່ອນໃດບ່ອນໜຶ່ງ ຫຼືເພີ່ມດັດສະນີເພື່ອໃຫ້ໄດ້ຜົນທີ່ດີກວ່າຈາກການສອບຖາມນີ້.

ຕາມ​ນັ້ນ​ແລ້ວ, ມັນ​ເປັນ​ສິ່ງ​ຈຳ​ເປັນ​ທີ່​ຈະ​ຕິດ​ຕາມ​ຄຳ​ຮ້ອງ​ຂໍ​ແລະ​ຄວາມ​ພຽງພໍ​ຂອງ​ມັນ. ໃຫ້ເອົາຕົວຢ່າງອື່ນຂອງການຕິດຕາມ. ແລະໃນທີ່ນີ້, ເຊັ່ນດຽວກັນ, ເບິ່ງຄືວ່າມີການຕິດຕາມທີ່ດີເລີດ. ມີຂໍ້ມູນກ່ຽວກັບການຈໍາລອງ, ມີຂໍ້ມູນກ່ຽວກັບການສົ່ງຜ່ານ, ການຂັດຂວາງ, ການນໍາໃຊ້ຊັບພະຍາກອນ. ທຸກຢ່າງແມ່ນດີ, ແຕ່ບໍ່ມີຂໍ້ມູນກ່ຽວກັບການຮ້ອງຂໍ. ມັນບໍ່ຊັດເຈນວ່າຄໍາຖາມໃດກໍາລັງແລ່ນຢູ່ໃນຖານຂໍ້ມູນຂອງພວກເຮົາ, ໄລຍະເວລາທີ່ພວກເຂົາກໍາລັງແລ່ນ, ຈໍານວນການສອບຖາມເຫຼົ່ານີ້ແມ່ນເທົ່າໃດ. ພວກເຮົາຈໍາເປັນຕ້ອງມີຂໍ້ມູນນີ້ຢູ່ໃນການຕິດຕາມຂອງພວກເຮົາສະເຫມີ.

ແລະເພື່ອໃຫ້ໄດ້ຮັບຂໍ້ມູນນີ້ພວກເຮົາສາມາດນໍາໃຊ້ໂມດູນ pg_stat_statements. ອີງໃສ່ມັນ, ທ່ານສາມາດສ້າງກາຟທີ່ຫລາກຫລາຍ. ຕົວຢ່າງ, ທ່ານສາມາດໄດ້ຮັບຂໍ້ມູນກ່ຽວກັບການສອບຖາມທີ່ພົບເລື້ອຍທີ່ສຸດ, ນັ້ນແມ່ນ, ກ່ຽວກັບການສອບຖາມທີ່ຖືກປະຕິບັດຫຼາຍທີ່ສຸດ. ແມ່ນແລ້ວ, ຫຼັງຈາກການນໍາໃຊ້, ມັນຍັງເປັນປະໂຫຍດຫຼາຍທີ່ຈະເບິ່ງມັນແລະເຂົ້າໃຈວ່າມີການຮ້ອງຂໍເພີ່ມຂຶ້ນ.

ທ່ານສາມາດຕິດຕາມການສອບຖາມທີ່ຍາວທີ່ສຸດ, ນັ້ນແມ່ນ, ຄໍາຖາມເຫຼົ່ານັ້ນໃຊ້ເວລາດົນທີ່ສຸດເພື່ອໃຫ້ສໍາເລັດ. ພວກເຂົາແລ່ນຢູ່ໃນໂປເຊດເຊີ, ພວກເຂົາບໍລິໂພກ I/O. ພວກເຮົາຍັງສາມາດປະເມີນອັນນີ້ໂດຍໃຊ້ fields total_time, mean_time, blk_write_time ແລະ blk_read_time.

ພວກເຮົາສາມາດປະເມີນແລະຕິດຕາມຄໍາຮ້ອງຂໍທີ່ຫນັກຫນ່ວງທີ່ສຸດໃນການນໍາໃຊ້ຊັບພະຍາກອນ, ຂໍ້ມູນທີ່ອ່ານຈາກແຜ່ນ, ທີ່ເຮັດວຽກກັບຫນ່ວຍຄວາມຈໍາ, ຫຼື, ກົງກັນຂ້າມ, ສ້າງບາງປະເພດຂອງການໂຫຼດ.

ພວກເຮົາສາມາດປະເມີນຄໍາຮ້ອງຂໍທີ່ເອື້ອອໍານວຍທີ່ສຸດ. ເຫຼົ່ານີ້ແມ່ນຄໍາຖາມທີ່ສົ່ງຄືນຈໍານວນແຖວຈໍານວນຫລາຍ. ຕົວຢ່າງ, ນີ້ອາດຈະເປັນບາງຄໍາຮ້ອງຂໍທີ່ພວກເຂົາລືມກໍານົດຂອບເຂດຈໍາກັດ. ແລະມັນພຽງແຕ່ສົ່ງຄືນເນື້ອໃນທັງຫມົດຂອງຕາຕະລາງຫຼືຄໍາຖາມໃນທົ່ວຕາຕະລາງສອບຖາມ.

ແລະທ່ານຍັງສາມາດຕິດຕາມການສອບຖາມທີ່ໃຊ້ໄຟລ໌ຊົ່ວຄາວຫຼືຕາຕະລາງຊົ່ວຄາວ.

ແລະພວກເຮົາຍັງມີຂະບວນການພື້ນຖານ. ຂະບວນການພື້ນຖານແມ່ນຈຸດກວດກາຕົ້ນຕໍຫຼືພວກເຂົາຍັງເອີ້ນວ່າດ່ານ, ເຫຼົ່ານີ້ແມ່ນ autovacuum ແລະ replication.

ຕົວຢ່າງອື່ນຂອງການຕິດຕາມ. ມີແຖບ Maintenance ຢູ່ເບື້ອງຊ້າຍ, ໄປຫາມັນແລະຫວັງວ່າຈະເຫັນບາງສິ່ງບາງຢ່າງທີ່ເປັນປະໂຫຍດ. ແຕ່ໃນທີ່ນີ້ແມ່ນພຽງແຕ່ເວລາຂອງການດໍາເນີນງານສູນຍາກາດແລະການເກັບກໍາສະຖິຕິ, ບໍ່ມີຫຍັງຫຼາຍ. ນີ້ແມ່ນຂໍ້ມູນທີ່ບໍ່ດີຫຼາຍ, ດັ່ງນັ້ນພວກເຮົາສະເຫມີຕ້ອງມີຂໍ້ມູນກ່ຽວກັບຂະບວນການພື້ນຖານຂອງຂະບວນການເຮັດວຽກຢູ່ໃນຖານຂໍ້ມູນຂອງພວກເຮົາແລະບໍ່ວ່າຈະມີບັນຫາໃດໆຈາກການເຮັດວຽກຂອງພວກເຂົາ.

ເມື່ອພວກເຮົາເບິ່ງຈຸດກວດກາ, ພວກເຮົາຄວນຈື່ໄວ້ວ່າຈຸດກວດກາຈະລ້າງຫນ້າເປື້ອນຈາກພື້ນທີ່ຫນ່ວຍຄວາມຈໍາທີ່ຖືກແບ່ງປັນໄປຫາແຜ່ນ, ຫຼັງຈາກນັ້ນສ້າງຈຸດກວດກາ. ແລະຈຸດກວດການີ້ສາມາດຖືກນໍາໃຊ້ເປັນສະຖານທີ່ສໍາລັບການຟື້ນຕົວຖ້າຫາກວ່າ PostgreSQL ໄດ້ຖືກຢຸດເຊົາຢ່າງກະທັນຫັນໃນເຫດສຸກເສີນ.

ດັ່ງນັ້ນ, ເພື່ອລ້າງຫນ້າ "ເປື້ອນ" ທັງຫມົດໃສ່ແຜ່ນ, ທ່ານຈໍາເປັນຕ້ອງຂຽນຈໍານວນທີ່ແນ່ນອນ. ແລະ, ຕາມກົດລະບຽບ, ໃນລະບົບທີ່ມີຫນ່ວຍຄວາມຈໍາຂະຫນາດໃຫຍ່, ນີ້ແມ່ນຫຼາຍ. ແລະຖ້າພວກເຮົາເຮັດຈຸດກວດກາເລື້ອຍໆໃນໄລຍະເວລາສັ້ນໆ, ປະສິດທິພາບຂອງແຜ່ນຈະຫຼຸດລົງຢ່າງຫຼວງຫຼາຍ. ແລະການຮ້ອງຂໍຂອງລູກຄ້າຈະທົນທຸກຈາກການຂາດຊັບພະຍາກອນ. ພວກເຂົາເຈົ້າຈະແຂ່ງຂັນສໍາລັບຊັບພະຍາກອນແລະຂາດຜົນຜະລິດ.

ຕາມນັ້ນແລ້ວ, ໂດຍຜ່ານ pg_stat_bgwriter ໂດຍໃຊ້ພາກສະຫນາມທີ່ກໍານົດພວກເຮົາສາມາດຕິດຕາມຈໍານວນຂອງຈຸດກວດກາທີ່ເກີດຂຶ້ນ. ແລະຖ້າພວກເຮົາມີຈຸດກວດກາຫຼາຍໃນໄລຍະເວລາທີ່ແນ່ນອນ (ໃນ 10-15-20 ນາທີ, ໃນເຄິ່ງຊົ່ວໂມງ), ຕົວຢ່າງ, 3-4-5, ຫຼັງຈາກນັ້ນ, ນີ້ສາມາດເປັນບັນຫາ. ແລະທ່ານຈໍາເປັນຕ້ອງຊອກຫາຢູ່ໃນຖານຂໍ້ມູນ, ເບິ່ງໃນການຕັ້ງຄ່າ, ສິ່ງທີ່ເຮັດໃຫ້ເກີດຄວາມອຸດົມສົມບູນຂອງດ່ານ. ບາງທີອາດມີການບັນທຶກອັນໃຫຍ່ອັນໃດນຶ່ງເກີດຂຶ້ນ. ພວກ​ເຮົາ​ສາ​ມາດ​ປະ​ເມີນ​ຜົນ​ວຽກ​ງານ​ໄດ້​ແລ້ວ, ເນື່ອງ​ຈາກ​ວ່າ​ພວກ​ເຮົາ​ໄດ້​ເພີ່ມ​ກາ​ຟິກ workload ແລ້ວ. ພວກເຮົາສາມາດປັບຕົວກໍານົດການກວດກາໄດ້ແລ້ວແລະໃຫ້ແນ່ໃຈວ່າພວກມັນບໍ່ມີຜົນກະທົບຢ່າງຫຼວງຫຼາຍຕໍ່ການປະຕິບັດການສອບຖາມ.

ຂ້ອຍກັບມາ autovacuum ອີກເທື່ອ ໜຶ່ງ, ເພາະວ່າມັນເປັນສິ່ງດັ່ງກ່າວ, ດັ່ງທີ່ຂ້ອຍເວົ້າ, ທີ່ສາມາດເພີ່ມປະສິດທິພາບທັງ disk ແລະ query, ສະນັ້ນມັນເປັນສິ່ງສໍາຄັນສະ ເໝີ ໄປທີ່ຈະປະເມີນປະລິມານຂອງ autovacuum.

ຈໍານວນພະນັກງານ autovacuum ໃນຖານຂໍ້ມູນແມ່ນຈໍາກັດ. ໂດຍຄ່າເລີ່ມຕົ້ນ, ມີສາມຄົນ, ດັ່ງນັ້ນ, ຖ້າພວກເຮົາມີພະນັກງານສາມຄົນເຮັດວຽກຢູ່ໃນຖານຂໍ້ມູນ, ນີ້ຫມາຍຄວາມວ່າ autovacuum ຂອງພວກເຮົາບໍ່ໄດ້ຖືກຕັ້ງຄ່າ, ພວກເຮົາຈໍາເປັນຕ້ອງເພີ່ມຂອບເຂດຈໍາກັດ, ປັບປຸງການຕັ້ງຄ່າ autovacuum ແລະເຂົ້າໄປໃນການຕັ້ງຄ່າ.
ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະເມີນວ່າພວກເຮົາມີພະນັກງານສູນຍາກາດໃດ. ບໍ່ວ່າມັນຖືກເປີດຕົວຈາກຜູ້ໃຊ້, DBA ມາແລະເປີດຕົວບາງປະເພດຂອງສູນຍາກາດດ້ວຍຕົນເອງ, ແລະນີ້ສ້າງການໂຫຼດ. ພວກເຮົາມີບັນຫາບາງຢ່າງ. ຫຼືນີ້ແມ່ນຈໍານວນຂອງສູນຍາກາດທີ່ unscrew ວຽກງານຕ້ານການ. ສໍາລັບບາງສະບັບຂອງ PostgreSQL ເຫຼົ່ານີ້ແມ່ນສູນຍາກາດຫນັກຫຼາຍ. ແລະພວກເຂົາສາມາດເພີ່ມການປະຕິບັດໄດ້ງ່າຍຍ້ອນວ່າພວກເຂົາອ່ານຕາຕະລາງທັງຫມົດ, ສະແກນຕັນທັງຫມົດໃນຕາຕະລາງນັ້ນ.

ແລະ, ແນ່ນອນ, ໄລຍະເວລາຂອງການສູນຍາກາດ. ຖ້າພວກເຮົາມີສູນຍາກາດທີ່ໃຊ້ເວລາດົນນານທີ່ເຮັດວຽກເປັນເວລາດົນນານ, ນີ້ຫມາຍຄວາມວ່າພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ເອົາໃຈໃສ່ອີກເທື່ອຫນຶ່ງກັບການຕັ້ງຄ່າສູນຍາກາດແລະບາງທີອາດພິຈາລະນາການຕັ້ງຄ່າຂອງມັນຄືນໃຫມ່. ເນື່ອງຈາກວ່າສະຖານະການອາດຈະເກີດຂື້ນໃນເວລາທີ່ສູນຍາກາດເຮັດວຽກຢູ່ໃນຕາຕະລາງເປັນເວລາດົນ (3-4 ຊົ່ວໂມງ), ແຕ່ໃນໄລຍະເວລາທີ່ສູນຍາກາດເຮັດວຽກ, ຈໍານວນຂະຫນາດໃຫຍ່ຂອງແຖວຕາຍສາມາດສະສົມຢູ່ໃນຕາຕະລາງອີກເທື່ອຫນຶ່ງ. ແລະທັນທີທີ່ສູນຍາກາດສໍາເລັດ, ລາວຈໍາເປັນຕ້ອງສູນຍາກາດຕາຕະລາງນີ້ອີກເທື່ອຫນຶ່ງ. ແລະພວກເຮົາມາຮອດສະຖານະການ - ເປັນສູນຍາກາດທີ່ບໍ່ມີທີ່ສິ້ນສຸດ. ແລະໃນກໍລະນີນີ້, ສູນຍາກາດບໍ່ໄດ້ຮັບມືກັບວຽກງານຂອງມັນ, ແລະຕາຕະລາງຄ່ອຍໆເລີ່ມບວມຂະຫນາດ, ເຖິງແມ່ນວ່າປະລິມານຂໍ້ມູນທີ່ເປັນປະໂຫຍດໃນມັນຍັງຄົງຢູ່ຄືກັນ. ດັ່ງນັ້ນ, ໃນໄລຍະສູນຍາກາດຍາວ, ພວກເຮົາສະເຫມີເບິ່ງການຕັ້ງຄ່າແລະພະຍາຍາມເພີ່ມປະສິດທິພາບມັນ, ແຕ່ໃນເວລາດຽວກັນເພື່ອໃຫ້ການປະຕິບັດການຮ້ອງຂໍຂອງລູກຄ້າບໍ່ທົນທຸກ.

ໃນປັດຈຸບັນບໍ່ມີການປະຕິບັດການຕິດຕັ້ງ PostgreSQL ທີ່ບໍ່ມີການຈໍາລອງການຖ່າຍທອດ. Replication ແມ່ນຂະບວນການຂອງການເຄື່ອນຍ້າຍຂໍ້ມູນຈາກຕົ້ນສະບັບໄປຫາ replica ໄດ້.

Replication ໃນ PostgreSQL ແມ່ນເຮັດຜ່ານບັນທຶກການເຮັດທຸລະກໍາ. ຕົວຊ່ວຍສ້າງບັນທຶກການເຮັດທຸລະກໍາ. ບັນທຶກການເຮັດທຸລະກໍາເດີນທາງຜ່ານການເຊື່ອມຕໍ່ເຄືອຂ່າຍກັບ replica, ແລະຫຼັງຈາກນັ້ນມັນຖືກຜະລິດຄືນໃຫມ່ໃນ replica. ມັນງ່າຍດາຍ.

ຕາມນັ້ນແລ້ວ, ມຸມມອງ pg_stat_replication ຖືກໃຊ້ເພື່ອຕິດຕາມຄວາມຊັກຊ້າຂອງການຈຳລອງ. ແຕ່ບໍ່ແມ່ນທຸກສິ່ງທຸກຢ່າງແມ່ນງ່າຍດາຍກັບນາງ. ໃນ​ສະ​ບັບ 10​, ການ​ເບິ່ງ​ໄດ້​ມີ​ການ​ປ່ຽນ​ແປງ​ຈໍາ​ນວນ​ຫນຶ່ງ​. ກ່ອນອື່ນ ໝົດ, ບາງຂົງເຂດໄດ້ຖືກປ່ຽນຊື່. ແລະບາງຊ່ອງຂໍ້ມູນໄດ້ຖືກເພີ່ມ. ໃນຮຸ່ນ 10, ປາກົດວ່າຊ່ອງຂໍ້ມູນອະນຸຍາດໃຫ້ທ່ານສາມາດຄາດຄະເນການຈໍາລອງ lag ໃນວິນາທີ. ມັນສະດວກສະບາຍຫຼາຍ. ກ່ອນທີ່ຈະສະບັບ 10, ມັນເປັນໄປໄດ້ທີ່ຈະຄາດຄະເນການຈໍາລອງ lag ໃນ bytes. ຕົວເລືອກນີ້ຍັງຄົງຢູ່ໃນຮຸ່ນ 10, i.e. ທ່ານສາມາດເລືອກສິ່ງທີ່ສະດວກກວ່າສໍາລັບທ່ານ - ຄາດຄະເນຄວາມຊັກຊ້າໃນ bytes ຫຼືຄາດຄະເນຄວາມລ້າໆໃນວິນາທີ. ຫຼາຍຄົນເຮັດທັງສອງ.

ແຕ່ຢ່າງໃດກໍ່ຕາມ, ເພື່ອປະເມີນຄວາມຊັກຊ້າຂອງການຈໍາລອງ, ທ່ານຈໍາເປັນຕ້ອງຮູ້ຕໍາແຫນ່ງຂອງບັນທຶກໃນການເຮັດທຸລະກໍາ. ແລະຕໍາແໜ່ງບັນທຶກການເຮັດທຸລະກໍາເຫຼົ່ານີ້ແມ່ນຢູ່ໃນມຸມເບິ່ງ pg_stat_replication. ເວົ້າຂ້ອນຂ້າງ, ພວກເຮົາສາມາດເອົາສອງຈຸດໃນບັນທຶກການເຮັດທຸລະກໍາໂດຍໃຊ້ຟັງຊັນ pg_xlog_location_diff(). ຄິດໄລ່ delta ລະຫວ່າງພວກມັນແລະເອົາການຈໍາລອງ lag ໃນ bytes. ມັນສະດວກຫຼາຍແລະງ່າຍດາຍ.

ໃນຮຸ່ນ 10, ຟັງຊັນນີ້ຖືກປ່ຽນຊື່ເປັນ pg_wal_lsn_diff(). ໂດຍທົ່ວໄປ, ໃນທຸກຫນ້າທີ່, ທັດສະນະ, ແລະຜົນປະໂຫຍດທີ່ຄໍາວ່າ "xlog" ໄດ້ຖືກພົບເຫັນ, ມັນໄດ້ຖືກແທນທີ່ດ້ວຍມູນຄ່າ "wal". ນີ້ໃຊ້ກັບທັງມຸມເບິ່ງແລະຫນ້າທີ່. ນີ້ແມ່ນການປະດິດສ້າງດັ່ງກ່າວ.

ນອກຈາກນັ້ນ, ໃນຮຸ່ນ 10, ສາຍໄດ້ຖືກເພີ່ມທີ່ສະແດງໃຫ້ເຫັນຄວາມຊັກຊ້າໂດຍສະເພາະ. ເຫຼົ່ານີ້ແມ່ນການຂຽນ lag, flush lag, replay lag. ນັ້ນແມ່ນ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະຕິດຕາມສິ່ງເຫຼົ່ານີ້. ຖ້າພວກເຮົາເຫັນວ່າພວກເຮົາມີຄວາມຊັກຊ້າໃນການຈໍາລອງ, ພວກເຮົາຈໍາເປັນຕ້ອງໄດ້ສືບສວນວ່າເປັນຫຍັງມັນປາກົດ, ມັນມາຈາກໃສແລະແກ້ໄຂບັນຫາ.

ເກືອບທຸກສິ່ງທຸກຢ່າງແມ່ນຢູ່ໃນຄໍາສັ່ງກັບ metrics ລະບົບ. ເມື່ອການກວດສອບໃດໆເລີ່ມຕົ້ນ, ມັນເລີ່ມຕົ້ນດ້ວຍການວັດແທກລະບົບ. ນີ້ແມ່ນການກໍາຈັດໂປເຊດເຊີ, ຫນ່ວຍຄວາມຈໍາ, swap, ເຄືອຂ່າຍແລະແຜ່ນ. ຢ່າງໃດກໍຕາມ, ຕົວກໍານົດການຈໍານວນຫຼາຍບໍ່ໄດ້ຢູ່ທີ່ນັ້ນໂດຍຄ່າເລີ່ມຕົ້ນ.

ຖ້າທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຄໍາສັ່ງກັບຂະບວນການລີໄຊເຄີນ, ຫຼັງຈາກນັ້ນມີບັນຫາກັບການລີໄຊເຄີນແຜ່ນ. ຕາມກົດລະບຽບ, ຜູ້ພັດທະນາການຕິດຕາມເພີ່ມຂໍ້ມູນກ່ຽວກັບການສົ່ງຕໍ່. ມັນສາມາດຢູ່ໃນ iops ຫຼື bytes. ແຕ່ພວກເຂົາລືມກ່ຽວກັບການ latency ແລະການນໍາໃຊ້ອຸປະກອນແຜ່ນ. ເຫຼົ່ານີ້ແມ່ນຕົວກໍານົດການທີ່ສໍາຄັນຫຼາຍທີ່ອະນຸຍາດໃຫ້ພວກເຮົາເພື່ອປະເມີນວິທີການໂຫຼດຂອງແຜ່ນຂອງພວກເຮົາແມ່ນຊ້າປານໃດ. ຖ້າພວກເຮົາມີ latency ສູງ, ນີ້ຫມາຍຄວາມວ່າມີບັນຫາບາງຢ່າງກັບແຜ່ນ. ຖ້າພວກເຮົາມີການນໍາໃຊ້ສູງ, ມັນຫມາຍຄວາມວ່າແຜ່ນທີ່ບໍ່ໄດ້ຮັບການຮັບມືກັບ. ເຫຼົ່ານີ້ແມ່ນຄຸນລັກສະນະທີ່ດີກ່ວາການສົ່ງຜ່ານ.

ຍິ່ງໄປກວ່ານັ້ນ, ສະຖິຕິເຫຼົ່ານີ້ຍັງສາມາດໄດ້ຮັບຈາກລະບົບໄຟລ໌ / proc, ຄືກັບທີ່ເຮັດສໍາລັບໂຮງງານຜະລິດຄືນໃຫມ່. ຂ້ອຍບໍ່ຮູ້ວ່າເປັນຫຍັງຂໍ້ມູນນີ້ບໍ່ໄດ້ຖືກເພີ່ມເຂົ້າໃນການຕິດຕາມ. ແຕ່ຢ່າງໃດກໍ່ຕາມ, ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະມີສິ່ງນີ້ໃນການຕິດຕາມຂອງທ່ານ.

ດຽວກັນໃຊ້ກັບການໂຕ້ຕອບເຄືອຂ່າຍ. ມີຂໍ້ມູນກ່ຽວກັບການສົ່ງຜ່ານເຄືອຂ່າຍໃນແພັກເກັດ, ໃນໄບຕ໌, ແຕ່ຢ່າງໃດກໍ່ຕາມ, ບໍ່ມີຂໍ້ມູນກ່ຽວກັບ latency ແລະບໍ່ມີຂໍ້ມູນກ່ຽວກັບການນໍາໃຊ້, ເຖິງແມ່ນວ່ານີ້ຍັງເປັນຂໍ້ມູນທີ່ເປັນປະໂຫຍດ.

ການຕິດຕາມໃດກໍ່ຕາມມີຂໍ້ບົກຜ່ອງ. ແລະບໍ່ວ່າທ່ານຈະຕິດຕາມແບບໃດກໍ່ຕາມ, ມັນຈະບໍ່ກົງກັບເງື່ອນໄຂບາງຢ່າງ. ແຕ່ຢ່າງໃດກໍ່ຕາມ, ພວກເຂົາກໍາລັງພັດທະນາ, ລັກສະນະໃຫມ່ແລະສິ່ງໃຫມ່ກໍາລັງຖືກເພີ່ມ, ດັ່ງນັ້ນເລືອກບາງສິ່ງບາງຢ່າງແລະເຮັດສໍາເລັດມັນ.

ແລະເພື່ອສໍາເລັດຮູບ, ທ່ານສະເຫມີຕ້ອງມີຄວາມຄິດຂອງສະຖິຕິທີ່ສະຫນອງໃຫ້ຫມາຍຄວາມວ່າແນວໃດແລະວິທີທີ່ທ່ານສາມາດນໍາໃຊ້ພວກມັນເພື່ອແກ້ໄຂບັນຫາ.

ແລະບາງຈຸດສໍາຄັນ:

• ທ່ານຄວນຕິດຕາມຄວາມພ້ອມຢູ່ສະ ເໝີ ແລະມີ dashboards ເພື່ອໃຫ້ທ່ານສາມາດປະເມີນໄດ້ໄວວ່າທຸກສິ່ງທຸກຢ່າງຢູ່ໃນຄໍາສັ່ງກັບຖານຂໍ້ມູນ.
• ທ່ານສະເຫມີຕ້ອງມີຄວາມຄິດກ່ຽວກັບສິ່ງທີ່ລູກຄ້າກໍາລັງເຮັດວຽກກັບຖານຂໍ້ມູນຂອງເຈົ້າເພື່ອກໍາຈັດລູກຄ້າທີ່ບໍ່ດີແລະຍິງພວກເຂົາລົງ.
• ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະເມີນວິທີທີ່ລູກຄ້າເຫຼົ່ານີ້ເຮັດວຽກກັບຂໍ້ມູນ. ທ່ານຈໍາເປັນຕ້ອງມີຄວາມຄິດກ່ຽວກັບວຽກງານຂອງທ່ານ.
• ມັນເປັນສິ່ງສໍາຄັນທີ່ຈະປະເມີນວິທີການເຮັດວຽກນີ້, ໂດຍການຊ່ວຍເຫຼືອຂອງຄໍາຖາມໃດ. ທ່ານ​ສາ​ມາດ​ປະ​ເມີນ​ຜົນ​ການ​ສອບ​ຖາມ​, ທ່ານ​ສາ​ມາດ​ປັບ​ປຸງ​ໃຫ້​ເຂົາ​ເຈົ້າ​, refactor ໃຫ້​ເຂົາ​ເຈົ້າ​, ສ້າງ​ດັດ​ຊະ​ນີ​ສໍາ​ລັບ​ເຂົາ​ເຈົ້າ​. ມັນເປັນສິ່ງສໍາຄັນຫຼາຍ.
• ຂະບວນການພື້ນຖານສາມາດສົ່ງຜົນກະທົບທາງລົບຕໍ່ຄໍາຮ້ອງຂໍຂອງລູກຄ້າ, ດັ່ງນັ້ນມັນຈໍາເປັນຕ້ອງຕິດຕາມວ່າພວກເຂົາບໍ່ໄດ້ໃຊ້ຊັບພະຍາກອນຫຼາຍເກີນໄປ.
• metrics ລະບົບຊ່ວຍໃຫ້ທ່ານສາມາດວາງແຜນການຂະຫຍາຍແລະເພີ່ມຄວາມອາດສາມາດຂອງເຄື່ອງແມ່ຂ່າຍຂອງທ່ານ, ດັ່ງນັ້ນມັນກໍ່ສໍາຄັນທີ່ຈະຕິດຕາມແລະປະເມີນພວກມັນເຊັ່ນກັນ.

ຖ້າຫາກວ່າທ່ານມີຄວາມສົນໃຈໃນຫົວຂໍ້ນີ້, ຫຼັງຈາກນັ້ນທ່ານສາມາດປະຕິບັດຕາມການເຊື່ອມຕໍ່ເຫຼົ່ານີ້.
http://bit.do/stats_collector - ນີ້ແມ່ນເອກະສານຢ່າງເປັນທາງການຈາກຜູ້ເກັບສະຖິຕິ. ມີລາຍລະອຽດຂອງສະຖິຕິການເບິ່ງທັງຫມົດແລະລາຍລະອຽດຂອງທຸກຂົງເຂດ. ທ່ານສາມາດອ່ານ, ເຂົ້າໃຈແລະວິເຄາະໃຫ້ເຂົາເຈົ້າ. ແລະອີງໃສ່ພວກມັນ, ສ້າງກາຟຂອງທ່ານແລະເພີ່ມພວກມັນເຂົ້າໃນການຕິດຕາມຂອງທ່ານ.

ການຮ້ອງຂໍຕົວຢ່າງ:
http://bit.do/dataegret_sql
http://bit.do/lesovsky_sql

ນີ້ແມ່ນຄັງເກັບຂອງບໍລິສັດຂອງພວກເຮົາແລະຂອງຂ້ອຍເອງ. ພວກມັນມີຕົວຢ່າງແບບສອບຖາມ. ບໍ່​ມີ​ການ​ສອບ​ຖາມ​ຈາກ​ການ​ເລືອກ * ຈາກ​ຊຸດ​ທີ່​ນັ້ນ​. ມີການສອບຖາມທີ່ກຽມພ້ອມແລ້ວກັບ joins, ການນໍາໃຊ້ຫນ້າທີ່ທີ່ຫນ້າສົນໃຈທີ່ຊ່ວຍໃຫ້ທ່ານປ່ຽນຕົວເລກດິບເປັນຄ່າທີ່ສາມາດອ່ານໄດ້, ສະດວກ, i.e. ເຫຼົ່ານີ້ແມ່ນ bytes, ເວລາ. ທ່ານສາມາດເລືອກເອົາພວກມັນ, ເບິ່ງພວກເຂົາ, ວິເຄາະ, ເພີ່ມພວກມັນເຂົ້າໃນການຕິດຕາມຂອງທ່ານ, ສ້າງການຕິດຕາມຂອງທ່ານໂດຍອີງໃສ່ພວກມັນ.

ຄໍາຖາມຂອງທ່ານ

ຄໍາຖາມ: ເຈົ້າເວົ້າວ່າທ່ານຈະບໍ່ໂຄສະນາຍີ່ຫໍ້, ແຕ່ຂ້ອຍກໍ່ຍັງຢາກຮູ້ - ເຈົ້າໃຊ້ dashboards ປະເພດໃດໃນໂຄງການຂອງເຈົ້າ?
ຄໍາຕອບ: ມັນແຕກຕ່າງກັນ. ມັນເກີດຂື້ນວ່າພວກເຮົາມາຫາລູກຄ້າແລະລາວມີການຕິດຕາມຂອງຕົນເອງແລ້ວ. ແລະພວກເຮົາແນະນໍາລູກຄ້າກ່ຽວກັບສິ່ງທີ່ຕ້ອງການເພີ່ມເຂົ້າໃນການຕິດຕາມຂອງພວກເຂົາ. ສະຖານະການທີ່ຮ້າຍແຮງທີ່ສຸດແມ່ນກັບ Zabbix. ເນື່ອງຈາກວ່າມັນບໍ່ມີຄວາມສາມາດໃນການສ້າງກາຟ TopN. ພວກເຮົາເອງໃຊ້ Okmeter, ເນື່ອງຈາກວ່າພວກເຮົາໄດ້ປຶກສາຫາລືກັບຄົນເຫຼົ່ານີ້ກ່ຽວກັບການຕິດຕາມກວດກາ. ພວກເຂົາເຈົ້າໄດ້ຕິດຕາມ PostgreSQL ໂດຍອີງໃສ່ຂໍ້ມູນສະເພາະດ້ານວິຊາການຂອງພວກເຮົາ. ຂ້ອຍກໍາລັງຂຽນໂຄງການສັດລ້ຽງຂອງຂ້ອຍເອງ, ເຊິ່ງເກັບກໍາຂໍ້ມູນຜ່ານ Prometheus ແລະເຮັດໃຫ້ມັນຢູ່ໃນ ກຣາຟານາ. ວຽກງານຂອງຂ້ອຍແມ່ນເພື່ອສ້າງຜູ້ສົ່ງອອກຂອງຂ້ອຍເອງໃນ Prometheus ແລະຫຼັງຈາກນັ້ນໃຫ້ທຸກສິ່ງທຸກຢ່າງຢູ່ໃນ Grafana.

ຄໍາຖາມ: ມີການປຽບທຽບຂອງບົດລາຍງານ AWR ຫຼື ... ການລວບລວມບໍ? ເຈົ້າຮູ້ເລື່ອງແບບນີ້ບໍ?
ຄໍາຕອບ: ແມ່ນແລ້ວ, ຂ້ອຍຮູ້ວ່າ AWR ແມ່ນຫຍັງ, ມັນເປັນສິ່ງທີ່ເຢັນ. ໃນ​ປັດ​ຈຸ​ບັນ​ມີ​ຄວາມ​ຫຼາກ​ຫຼາຍ​ຂອງ​ລົດ​ຖີບ​ທີ່​ປະ​ຕິ​ບັດ​ປະ​ມານ​ຮູບ​ແບບ​ດັ່ງ​ຕໍ່​ໄປ​ນີ້​. ໃນບາງຊ່ວງເວລາ, ບາງເສັ້ນພື້ນຖານຖືກຂຽນໃສ່ PostgreSQL ດຽວກັນ ຫຼືໃສ່ບ່ອນເກັບຂໍ້ມູນແຍກຕ່າງຫາກ. ທ່ານສາມາດ google ໃຫ້ເຂົາເຈົ້າໃນອິນເຕີເນັດ, ພວກເຂົາເຈົ້າຢູ່ທີ່ນັ້ນ. ຫນຶ່ງໃນນັກພັດທະນາຂອງສິ່ງດັ່ງກ່າວກໍາລັງນັ່ງຢູ່ໃນເວທີ sql.ru ໃນກະທູ້ PostgreSQL. ເຈົ້າສາມາດຈັບລາວຢູ່ທີ່ນັ້ນ. ແມ່ນແລ້ວ, ມີສິ່ງດັ່ງກ່າວ, ພວກເຂົາສາມາດຖືກນໍາໃຊ້. ບວກຢູ່ໃນຂອງມັນ pgCenter ຂ້ອຍຍັງຂຽນສິ່ງທີ່ອະນຸຍາດໃຫ້ທ່ານເຮັດສິ່ງດຽວກັນ.

PS1 ຖ້າທ່ານກໍາລັງໃຊ້ postgres_exporter, ທ່ານກໍາລັງໃຊ້ dashboard ໃດ? ມີຫຼາຍຂອງພວກເຂົາ. ພວກມັນລ້າສະໄຫມແລ້ວ. ບາງທີຊຸມຊົນຈະສ້າງແມ່ແບບທີ່ມີການປັບປຸງບໍ?

PS2 ຖອນ pganalze ເພາະວ່າມັນເປັນການສະເຫນີ SaaS ທີ່ເປັນເຈົ້າຂອງເຊິ່ງເນັ້ນໃສ່ການຕິດຕາມການປະຕິບັດແລະການແນະນໍາການປັບອັດຕະໂນມັດ.

ພຽງແຕ່ຜູ້ໃຊ້ລົງທະບຽນສາມາດເຂົ້າຮ່ວມໃນການສໍາຫຼວດ. ເຂົ້າ​ສູ່​ລະ​ບົບກະລຸນາ.

ການກວດສອບ postgresql ທີ່ເປັນເຈົ້າພາບຂອງຕົນເອງ (ກັບ dashboard) ທ່ານພິຈາລະນາທີ່ດີທີ່ສຸດ?

• 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%pganalyze ເປັນ 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