modülünüzü gözden geçirerek bu hatayı tekrar etmemesini sağlamanızı
tavsiye ederim...
On Mon, Mar 30, 2009 at 9:33 AM, Bayram Karagoz
karagoz.bay...@gmail.com wrote:
İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir
değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış
olabileceğiniz asıl nokta burada kullandığınız yazılımın
transactionların bir kısmını gereksiz yere idle tuttuğudur.
teşekkürler kerem bey,
idle in transaction süreçleri sistemimde bir modülün açmış olduğu
süreçlerdir. bu süreçlerden birini kill ettiğim
zaman diğerleri de otomatik olarak kill oldu ve slony de problem yok gibi
görünüyor. fakat modülleri her restart edişimde bu süreçler
tekrardan çalışmaya başlıyor. geçici bir çözüm bulduk ama daha optimum
çözümlere de açığım.
On Fri, 2009-03-27 at 15:11 +0200, Kerem Erciyes wrote:
Merhaba,
İkinci ihtimalde bahsedilen open_idle_transaction_timeout gibi bir
değişkenin ileride eklenmesinin düşünüldüğü. Ama atlamış
olabileceğiniz asıl nokta burada kullandığınız yazılımın
transactionların bir kısmını gereksiz yere idle tuttuğudur.
Kolay Gelsin,
Kerem
On Thu, Mar 26, 2009 at 10:14 AM, Bayram KARAGOZ
bayram.kara...@empatiq.com wrote:
merhaba
freebsd üzerine kurulu iki farklı sunucudaki iki ayrı postgresql
veritabanını slony ile replikasyon işlemine tabii tuttum. replikasyonun
yapılmasında herhangi bir problem yok. master sunucuda yaptığım her türlü
işlem anında slave veritabanına da ekleniyor. fakat bir süre sonra master
sunucuda cpu ve io yükselmesi meydana geliyor. süreçleri incelediğimde
master üzerinde çalışan bir processin bu probleme sebep olduğunun farkına
vardım. bu süreç sürekli çalıştığı zaman veritabanına yapılan diğer
sorgularda takılmalar meydana geliyor ve bazen sorgu cevapları çok geç
geliyor. bu süreci sonlandırdığım zaman tekrar sunucu eski haline dönüyor
fakat replikasyon işlemi hata veriyor. çalışan süreç aşağıda
gösterilmektedir.
ön bilgi;
master sunucu ip : 10.0.10.231
slave sunucu ip : 10.0.10.232
sippy=# SELECT procpid,client_addr, current_query,query_start from
pg_stat_activity where current_query NOT LIKE 'IDLE';
procpid | client_addr |
current_query |
query_start
-+-++---
84329 | 10.0.10.232 | fetch 100 from
LOG;
| 2009-03-25 13:05:57.007739+02
yukarıda gösterilen süreç slave sunucu tarafından gönderilen bir istek
olduğu client_addr kısmında gösteriliyor. ( fetch 100 from LOG; ) sorgusuyla
alakalı slony FAQ da araştırma yaptığımda bu problemin birkaç sebepten
kaynaklanabileceği söyleniyor;
14. Some nodes start consistently falling behind
I have been running Slony-I on a node for a while, and am seeing system
performance suffering.
I'm seeing long running queries of the form:
fetch 100 from LOG;
This can be characteristic of pg_listener (which is the table containing
NOTIFY data) having plenty of dead tuples in it. That makes NOTIFY events
take a long time, and causes the affected node to gradually fall further and
further behind.
You quite likely need to do a VACUUM FULL on pg_listener, to vigorously
clean it out, and need to vacuum pg_listener really frequently. Once every
five minutes would likely be AOK.
Slon daemons already vacuum a bunch of tables, and cleanup_thread.c
contains a list of tables that are frequently vacuumed automatically. In
Slony-I 1.0.2, pg_listener is not included. In 1.0.5 and later, it is
regularly vacuumed, so this should cease to be a direct issue.
There is, however, still a scenario where this will still bite. Under
MVCC, vacuums cannot delete tuples that were made obsolete at any time
after the start time of the eldest transaction that is still open. Long
running transactions will cause trouble, and should be avoided, even on
subscriber nodes.
anladığım kadarıyla replikasyon işlemiyle alakalı NOTIFY bilgileri sürekli
olarak pg_listener tablosunda tutuluyor ve güncelleniyor. bu sebepten bu
tabloda dead tuple lar oluşuyor. bu yüzden bu tablonun yaklaşık 5 dk bir
vacuum lanması gerektiği söyleniyor. fakat slony 1.0.5 ve sonra versiyonlar
bu işi kendisi yapıyor deniyor. benim kullandığım slony versiyonu 1.2.11. bu
yüzden bu ihtimalin olması imkansız gibi görünüyor.
sippy=# SELECT * from pg_listener ;
relname | listenerpid | notification
--+-+--
_ssp_Restart | 85920 | 0
(1 row)
pkg_version -v |grep slony
slony1-1.2.11 needs updating (port has 1.2.15)
pkg_version -v |grep postgre*
postgresql-client-8.2.5_1 needs updating (port has 8.2.12)
postgresql-server-8.2.5_2 needs updating (port has 8.2.12)
2. neden olarak aşağıdaki ihtimalden bahsediliyor;
25. Replication has been