{"id":1970,"date":"2015-05-07T02:20:45","date_gmt":"2015-05-06T23:20:45","guid":{"rendered":"http:\/\/www.profelis.com.tr\/tr\/blog\/?p=1970"},"modified":"2023-02-01T10:58:01","modified_gmt":"2023-02-01T07:58:01","slug":"postgresql-101-sorgularim-neden-yavasliyor","status":"publish","type":"post","link":"https:\/\/profelis.com.tr\/en\/2015\/05\/07\/postgresql-101-sorgularim-neden-yavasliyor\/","title":{"rendered":"PostgreSQL 101: Sorgular\u0131m Neden Yava\u015fl\u0131yor?"},"content":{"rendered":"<h2>PostgreSQL 101: Sorgular\u0131m Neden Yava\u015fl\u0131yor?<\/h2>\n<p>Yava\u015f sorgulardan bahsetmiyoruz, birden bire, durup dururken, d\u00fcne kadar normal \u00e7al\u0131\u015f\u0131rken yava\u015flad\u0131\u011f\u0131n\u0131 farketti\u011fimiz sorgulardan bahsedelim. Milisaniyeler s\u00fcrerken saniyeler s\u00fcrmeye ba\u015flayan, birka\u00e7 saniye s\u00fcrerken dakikalar s\u00fcren sorgular bunlar.<\/p>\n<p>\u0130lk bak\u0131\u015fta dikkat edece\u011fimiz bir ka\u00e7 noktay\u0131 ele al\u0131p eleyelim \u00f6ncelikle:<\/p>\n<h2>D\u00fcne g\u00f6re ne de\u011fi\u015fti?<\/h2>\n<p><a title=\"Matrix\" href=\"http:\/\/matrix.wikia.com\/wiki\/Matrix\" target=\"_blank\" rel=\"noopener\">Matrix<\/a>&#8216;te bir de\u011fi\u015fiklik yap\u0131ld\u0131\u011funda olu\u015fan, tekrarlayan g\u00f6r\u00fcnt\u00fclere diyoruz:\u00a0<strong>d\u00e9j\u00e0 vu!<\/strong>\u00a0\u0130lk bakaca\u011f\u0131m\u0131z kontrol noktalar\u0131, son yap\u0131lan de\u011fi\u015fiklikler olacakt\u0131r. Genellikle de bu yava\u015flamalar\u0131n olas\u0131 \u015f\u00fcphelileri bu de\u011fi\u015fikliklerdir.<\/p>\n<ul>\n<li>Yeni bir veri mi i\u00e7eriye ald\u0131k, ani bir b\u00fcy\u00fcme mi s\u00f6z konusu oldu?\u00a0Sorgular\u0131n d\u00fcne g\u00f6re dikkate de\u011fer \u015fekilde daha fazla veri getirip getirmedi\u011fi kontrol edilmelidir.<\/li>\n<li>Bir indeks ile mi oynad\u0131k? De\u011fi\u015fim g\u00fcnl\u00fc\u011f\u00fc tutuyorsan\u0131z buna bakmal\u0131s\u0131n\u0131z. Bu t\u00fcr durumlarda sorumlulun yan koltukta oturuyor olmas\u0131 kar\u015f\u0131la\u015f\u0131lmad\u0131k bir durum de\u011fildir \ud83d\ude42<\/li>\n<li>Bir monit\u00f6r\/izleme arac\u0131 m\u0131 ekledik? Cacti, Munin gibi izleme ara\u00e7lar\u0131 s\u00fcrekli olarak CPU, bellek, disk kullan\u0131m\u0131 gibi bilgileri fazla s\u0131k \u015fekilde toplamaya ba\u015flam\u0131\u015f olabilir mi?<\/li>\n<\/ul>\n<p>Daha \u00f6nceden kurulu bir izleme arac\u0131m\u0131z varsa bu sefer de i\u015flemci, bellek, disk ve a\u011f kullan\u0131m\u0131 gibi de\u011ferlerin de\u011fi\u015fikli\u011fine bakmak iyi bir ba\u015flang\u0131\u00e7 noktas\u0131 olabilir. \u00d6rne\u011fin, RAID sistemindeki disklerden birisi devre d\u0131\u015f\u0131 kalm\u0131\u015f ve o an yedek disk sisteme ekleniyor dolay\u0131s\u0131 ile \u00e7ok y\u00fcksek I\/O de\u011ferleri g\u00f6r\u00fcn\u00fcyor olabilir.<\/p>\n<h2>Veritaban\u0131 Analizi<\/h2>\n<p>Ola\u011fan \u015f\u00fcphelilerin sorgusundan bir\u015fey \u00e7\u0131kmad\u0131ysa veritaban\u0131m\u0131za bir bakal\u0131m:<\/p>\n<pre>db_01=# analyse;\nANALYZE\nTime: 6331.113 ms\n<\/pre>\n<p>Ucuz ve \u00e7ok kullan\u0131lan bir y\u00f6ntem olmakla beraber, en basit, genellikle bir derde \u00e7are olmayan, T\u00fcrk usul\u00fc tabir etti\u011fimiz, kafaya iki pat pat yapmak anlam\u0131na gelir. Ama e\u011fer dikkate de\u011fer bir d\u00fczelme g\u00f6zlemlerseniz o zaman bilin ki <strong>autovacuum<\/strong> i\u015flevini do\u011fru \u015fekilde yerine getiremiyor demektir. Bu durumda dikkatinizi bu konuya verebilirsiniz.<\/p>\n<p>Bazen, d\u0131\u015far\u0131dan veri ekleme vs sebeplerle belirli baz\u0131 tablolar\u0131n veri boyutu ani \u015fekilde art\u0131r\u0131lm\u0131\u015f ancak tablo istatistikleri g\u00fcncellenmemi\u015f olabilir. B\u00f6yle bir durumda bahsi ge\u00e7en sorgular i\u00e7in istatistik tabanl\u0131 optimizasyon motoru k\u00f6t\u00fc bir plan se\u00e7mi\u015f olabilir. Bu durumda ANALYZE komutu elle \u00e7al\u0131\u015ft\u0131r\u0131ld\u0131\u011f\u0131nda tablo istatistiklerini g\u00fcnceller ve sorgular do\u011fru planlar ile \u00e7al\u0131\u015fmaya ba\u015flar.<\/p>\n<p>Yava;layan sorgulari izole ederek \u00e7al\u0131\u015ft\u0131rarak deneyebilirsiniz. Development, test vb sistemleriniz varsa veya read-only replikan\u0131z \u00fczerinde de ayn\u0131 performans\u0131 m\u0131 sergiliyorlar? Ayn\u0131 anda birlikte \u00e7al\u0131\u015fan sorgular, birbirleri ile bellek i\u00e7in rekabet ederler. Bu rekabette sizin sorgunuz kaybediyor olabilir.<\/p>\n<p>Ayn\u0131 sorgunun ikinci defa \u00e7al\u0131\u015ft\u0131r\u0131lmas\u0131 durumunda da performans kayb\u0131 ya\u015fan\u0131yor mu? \u0130\u015fte bu durum, yukar\u0131da a\u00e7\u0131klad\u0131\u011f\u0131m\u0131z gibi bellek ile ilgili bir durumu i\u015faret eder. Sonu\u00e7lar belle\u011fe s\u0131\u011fm\u0131yor veya di\u011fer sorgular taraf\u0131ndan bellek d\u0131\u015f\u0131na at\u0131l\u0131yor olabilir.<\/p>\n<h2>Tablo ve Dizin \u015ei\u015fmesi (<em>Index Bloat<\/em>)<\/h2>\n<div class=\"page\" title=\"Page 223\">\n<div class=\"layoutArea\">\n<div class=\"column\">\n<p>Zaman i\u00e7erisinde olu\u015fabilen sorunlardan birisi de bak\u0131m i\u015flemlerinin do\u011fru \u015fekilde \u00e7al\u0131\u015ft\u0131r\u0131lmamas\u0131 sonucu olu\u015fabilen tablo \u015fi\u015fmesi sorunudur. <a href=\"https:\/\/wiki.postgresql.org\/wiki\/MVCC\" target=\"_blank\" rel=\"noopener noreferrer\">MVCC<\/a>&#8216;nin \u00e7al\u0131\u015fma prensipleri gere\u011fi, tablolar bir \u00e7ok eski s\u00fcr\u00fcm veriyi de saklamaya devam eder. Bu eski s\u00fcr\u00fcmler bir \u015fekilde silinmezler ise tablo \u015fi\u015fmesi sorunu ortaya \u00e7\u0131kar.<\/p>\n<p>Bu problemin olu\u015fmas\u0131na birka\u00e7 farkl\u0131 sebep neden olabilir ki bunlar\u0131n hemen hepsi INSERT, UPDATE ve DELETE c\u00fcmlecikleri ile alakal\u0131d\u0131r. Bu i\u015flemler esnas\u0131nda oto vakum (<em>autovacuum<\/em>) eski verinin kald\u0131r\u0131lmas\u0131 i\u015flemini yerine getiremezse ve hatta bu i\u015flevi yerine getirmi\u015f ve eski s\u00fcr\u00fcmleri silmi\u015f olsa dahi tablo eski s\u00fcr\u00fcmleri (<em>tuples<\/em>) de i\u00e7eren veri boyutu ile kal\u0131r. \u00d6yle ki sadece tek sat\u0131r veri i\u00e7eren tablonun birka\u00e7 gigabyte boyutunda g\u00f6z\u00fckt\u00fc\u011f\u00fc g\u00f6r\u00fclmemi\u015f \u015fey de\u011fildir.<\/p>\n<p>B\u00f6yle durumlar ile kar\u015f\u0131la\u015f\u0131ld\u0131\u011f\u0131nda a\u015fa\u011f\u0131daki sorgu yard\u0131mc\u0131 olacakt\u0131r:<\/p>\n<pre>SELECT\n   pg_relation_size(relid) as tablesize, \n   schemaname, relname, n_live_tup\nFROM pg_stat_user_tables\nWHERE relname = ;\n<\/pre>\n<p>Tablo boyutunu g\u00f6steren <strong>tablesize<\/strong> ile <strong>n_live_tup<\/strong>\u00a0de\u011feri aras\u0131ndaki ili\u015fkiyi g\u00f6zlemlemelisiniz. \u00d6yle ki, e\u011fer tablo boyutu tablo yap\u0131s\u0131na g\u00f6re g\u00f6rece b\u00fcy\u00fck, ama sat\u0131r say\u0131s\u0131 \u00e7ok az ise muhtemelen bir tablo \u015fi\u015fmesi sorunu s\u00f6z konusudur. B\u00f6yle bir durumda tablodaki dizinlerin (<em>indexes<\/em>) de \u015fi\u015fmi\u015f olmas\u0131 ve sorgular\u0131n yava\u015flamas\u0131na sebep olmas\u0131 ka\u00e7\u0131n\u0131lmazd\u0131r.<\/p>\n<p><strong>Dikkat:<\/strong> Tablo yap\u0131s\u0131na g\u00f6re g\u00f6rece b\u00fcy\u00fckl\u00fckten kas\u0131t, tablo i\u00e7erisinde blob, b\u00fcy\u00fck text alanlar\u0131n olup olmamas\u0131na ili\u015fkin bir g\u00f6receliliktir, dikkat ediniz, tabloda hali haz\u0131rda b\u00fcy\u00fck boyutlu veri de tutuluyor olabilir. Tutulan verinin boyutuna g\u00f6re bir b\u00fcy\u00fckl\u00fck k\u0131yaslamas\u0131 yap\u0131n\u0131z.<\/p>\n<\/div>\n<\/div>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Yava\u015f sorgulardan bahsetmiyoruz, birden bire, durup dururken, d\u00fcne kadar normal \u00e7al\u0131\u015f\u0131rken yava\u015flad\u0131\u011f\u0131n\u0131 farketti\u011fimiz sorgulardan bahsedelim. Milisaniyeler s\u00fcrerken saniyeler s\u00fcrmeye ba\u015flayan, birka\u00e7 saniye s\u00fcrerken dakikalar s\u00fcren sorgular bunlar.<\/p>","protected":false},"author":3,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[75,45],"tags":[48,60],"class_list":["post-1970","post","type-post","status-publish","format-standard","hentry","category-postgresql","category-yazi","tag-enterprisedb","tag-postgresql"],"_links":{"self":[{"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/posts\/1970","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/users\/3"}],"replies":[{"embeddable":true,"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/comments?post=1970"}],"version-history":[{"count":0,"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/posts\/1970\/revisions"}],"wp:attachment":[{"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/media?parent=1970"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/categories?post=1970"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/profelis.com.tr\/en\/wp-json\/wp\/v2\/tags?post=1970"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}