[FreeBSD] sistemin kendiliğinden downolmasının nedenleri
merhaba freebsd de kullanılan RAM ve SWAP kapasitesi maksimum seviyede olduğu zamanlarda sisteme hiçbir şekilde ( http, ssh, ping ) ulaşılamaması veya herhangi bir nedenden dolayı yine sisteme hiçbir şekilde ulaşılamayıp restarttan sonra düzelmesinin sebepleri neler olabilir ? Bayram KARAGÖZ Sistem Destek Mühendisi System Support Engineer empatiq iletişim teknolojileri GSM : +90 (541) 254 64 01 Tel : +90 (212) 217 50 80 Fax : +90 (212) 266 65 59 E-Mail : bayram.kara...@empatiq.com
Re: [FreeBSD] slony ile replikasyon problemi
teşekkürler kerem bey,
Re: [FreeBSD] slony ile replikasyon problemi
> > > > İ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 > 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 ''; > > 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ı N
Re: [FreeBSD] slony ile replikasyon problemi
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 ''; 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 slowing down, I'm seeing FETCH 100 FROM LOG queries running for a long time, sl_log_1 is growing, and performance is, well, generally getting steadily worse. There are actually a number of possible causes for this sort of thing. There is a question involving similar pathology where the problem is that pg_listener grows because it is not vacuumed. Another " proximate cause " for this growth is for there to be a connection connected to the node that sits IDLE IN TRANSACTION for a very long time. That open transaction will have multiple negative effects, all of which will adversely affect performance: Vacuums on all tables, including pg_listener, will not clear out dead tuples from before the start of the idle transaction. The cleanup thread will be unable to clean out entries in sl_log_1 and sl_seqlog, with the result that these tables will grow, ceaselessly, until the transaction is closed. You can monitor for this condition inside the database only if the PostgreSQL postgresql.conf parameter stats_command_string is set to true. If that is set, then you may submit the query select * from pg_stat_activity where current_query like '%IDLE% in transaction'; which will find relevant activi
[FreeBSD] slony ile replikasyon problemi
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 ''; 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 slowing down, I'm seeing FETCH 100 FROM LOG queries running for a long time, sl_log_1 is growing, and performance is, well, generally getting steadily worse. There are actually a number of possible causes for this sort of thing. There is a question involving similar pathology where the problem is that pg_listener grows because it is not vacuumed. Another " proximate cause " for this growth is for there to be a connection connected to the node that sits IDLE IN TRANSACTION for a very long time. That open transaction will have multiple negative effects, all of which will adversely affect performance: Vacuums on all tables, including pg_listener, will not clear out dead tuples from before the start of the idle transaction. The cleanup thread will be unable to clean out entries in sl_log_1 and sl_seqlog, with the result that these tables will grow, ceaselessly, until the transaction is closed. You can monitor for this condition inside the database only if the PostgreSQL postgresql.conf parameter sta
Re: [FreeBSD] ethernet kartı problem
verdiğiniz bilgiler için teşekkür ederim. fxp0 ethernet kartımı disable edip sadece em0 ı aktif edince problem çözüldü. fakat ben olası durumlarda em0 da bir problem olmasına karşın fxp0 dan sistemime erişmek istiyordum. ayrıca bu ethernet kartlarına da farklı networklerden ip verme imkanım yok. fakat 2 ethetnet kartına da aynı aynı networkten ip vermenin sorunlara yol açabileceğini söylüyorsunuz. ne gibi problemler yaşayabilirim? biraz daha açabilirmisiniz? teşekkürler...
[FreeBSD] ethernet kartı problem
merhaba ilginç bir problemle karşı karşıyayım. yardımcı olabilirseniz çok sevinirim. problemim sistem üzerinden bazı paketlerin geç gönderilmesidir. FreeBSD 6.3 release sistemimde 2 adet ethernet kartım var; fxp0: flags=8843 mtu 1500 options=b inet 10.0.10.20 netmask 0xfff0 broadcast 84.51.47.111 ether 00:07:e9:31:14:d2 media: Ethernet autoselect (100baseTX ) status: active em0: flags=8847 mtu 1500 options=b inet 10.0.10.30 netmask 0xfff0 broadcast 84.51.47.111 ether 00:07:e9:31:14:d3 media: Ethernet autoselect (1000baseTX ) status: active lo0: flags=8049 mtu 16384 inet 127.0.0.1 netmask 0xff00 < fxp0 ethernet kartım 100baseTX lik em0 ethernet kartım 1000baseTX lik olarak görünüyor ve iki kartta aktif durumda. ben sistem üzerinden gönderilecek paketlerin em0 üzerinden gitmesini istiyorum ve başka bir sunucuda bulunan client uygulamasından bu serverdaki em0 ethernet kartına atanan 10.0.10.30 ipsine paket gönderiyorum fakat paketler genelde fxp0 olmak üzere nadiren de em0 üzerinden geçiyor. bazen de alttaki gibi em0 üzerinden giriş fxp0 üzerinden çıkış oluyor. > /0 /1 /2 /3 /4 /5 /6 /7 /8 /9 /10 Load Average Interface Traffic PeakTotal lo0 in 0.000 KB/s 0.000 KB/s 47.012 KB out 0.000 KB/s 0.000 KB/s 47.012 KB em0 in 0.063 KB/s 4.092 KB/s4.720 MB out 0.000 KB/s 0.000 KB/s0.410 KB fxp0 in 0.000 KB/s 0.116 KB/s1.475 MB out 0.157 KB/s 4.009 KB/s7.315 MB < fxp0 a ait olan 10.0.10.20 ipsini hiçbir yerde kullanmama rağmen genelde bütün paketler bu ethernet kartı üzerinden gidiyor. ipleri değiştirip tekrar deneme yaptığımda bu seferde bütün paketler sadece fxp0 üzerinden iletiliyor. sonuç olarak bir türlü em0 ethernet kartını bütün paketlerin üzerinden geçecek şekilde devreye alamıyorum. donanımsal bir problemmi yoksa gözden kaçırdığım bir noktamı var anlayamadım. yardımlarınız için şimdiden teşekkürler...
[FreeBSD] ssh girişi ipkısıtlaması
merhaba ben tcpwrappers üzerinden birtakım sınırlandırmalar yapmak istiyordum. bir firewall uygulaması kullanmak yerine freebsd de bulunan tcpwrappers uygulamasının işimi rahatlıkla çözeceğini düşündüm. Bu vesile ile öncelikle ssh girişlerinde sınırlama yapmam gerekti. bunun için freebsd handbook tan yararlanarak öncelikle inetd servisini aktif hale getirdim ( http://www.freebsd.org/doc/en_US.ISO8859-1/books/handbook/network-inetd.html ) . işlemimi tamamladıktan sonra inetd servisini kontrol ettim. #/etc/rc.d/inetd status inetd is running as pid 998. bir problem yok gibi görünüyor. daha sonra /etc/hosts.allow altında sadece ssh servisini kısıtlamak için; sshd : ALL : deny satırını uygun yere ekledim. /etc/host.allow dosyası çalıştırılırken yukarıdan aşağıya doğru sorgulandığını bildiğim için gerekli kısıtlamayı; ALL : ALL : allow parametresinin altına yaptım. çünkü başlangıçta bütün servislerin erişimi açık olarak atanmış. sonra kısım kısım sınırlandırma yapıyoruz deniyor. bu işlemi de tamamladıktan sonra inetd servisini restart etmem gerektiğini bilerek restart işlemini gerçekleştiriyorum. ardından ssh giriş denemesi yaptığımda giriş yapılabiliyor. 2. si u şekilde çalışmadığını gördükten sonra /etc/hosts.allow dosyasının çalışmasını kontrol etmek amacıyla ALL : ALL : allow parametresini açıklama satırı haline getirip tekrar ssh giriş denemesi yaptığımda amacıma ulaşıyorum. fakat heralde bütün girişleri de kapatmış oluyorum. acaba problem nerededir? yardımcı olursanız çok sevineceğim. teşekkürler. /etc/hosts.allow dosyamın içeriğini aşağıda görebilirsiniz. # # hosts.allow access control file for "tcp wrapped" applications. # $FreeBSD: src/etc/hosts.allow,v 1.19.8.2 2007/01/20 02:19:57 csjp Exp $ # # NOTE: The hosts.deny file is deprecated. # Place both 'allow' and 'deny' rules in the hosts.allow file. # See hosts_options(5) for the format of this file. # hosts_access(5) no longer fully applies. #_ _ _ # | | __ __ __ _ _ __ ____ __ | | ___ | | # | _| \ \/ / / _` | | '_ ` _ \ | '_ \ | | / _ \ | | # | |___ > < | (_| | | | | | | | | |_) | | | | __/ |_| # |_| /_/\_\ \__,_| |_| |_| |_| | .__/ |_| \___| (_) # |_| # !!! This is an example! You will need to modify it for your specific # !!! requirements! # Start by allowing everything (this prevents the rest of the file # from working, so remove it when you need protection). # The rules here work on a "First match wins" basis. ALL : ALL : allow # Wrapping sshd(8) is not normally a good idea, but if you # need to do it, here's how #sshd : .evil.cracker.example.com : deny sshd : ALL : deny # Protect against simple DNS spoofing attacks by checking that the # forward and reverse records for the remote host match. If a mismatch # occurs, access is denied, and any positive ident response within # 20 seconds is logged. No protection is afforded against DNS poisoning, # IP spoofing or more complicated attacks. Hosts with no reverse DNS # pass this rule. ALL : PARANOID : RFC931 20 : deny # Allow anything from localhost. Note that an IP address (not a host # name) *MUST* be specified for rpcbind(8). ALL : localhost 127.0.0.1 : allow # Comment out next line if you build libwrap with NO_INET6=yes. ALL : [::1] : allow ALL : my.machine.example.com 192.0.2.35 : allow # To use IPv6 addresses you must enclose them in []'s ALL : [fe80::%fxp0]/10 : allow ALL : [fe80::]/10 : deny ALL : [2001:db8:2:1:2:3:4:3fe1] : deny ALL : [2001:db8:2:1::]/64 : allow # Sendmail can help protect you against spammers and relay-rapers sendmail : localhost : allow sendmail : .nice.guy.example.com : allow sendmail : .evil.cracker.example.com : deny sendmail : ALL : allow # Exim is an alternative to sendmail, available in the ports tree exim : localhost : allow exim : .nice.guy.example.com : allow exim : .evil.cracker.example.com : deny exim : ALL : allow # Rpcbind is used for all RPC services; protect your NFS! # (IP addresses rather than hostnames *MUST* be used here) rpcbind : 192.0.2.32/255.255.255.224 : allow rpcbind : 192.0.2.96/255.255.255.224 : allow rpcbind : ALL : deny # NIS master server. Only local nets should have access # (Since this is an RPC service, rpcbind needs to be considered) ypserv : localhost : allow ypserv : .unsafe.my.net.example.com : deny ypserv : .my.net.example.com : allow ypserv : ALL : deny # Provide a small amount of protection for ftpd ftpd : localhost : allow ftpd : .nice.guy.example.com : allow ftpd : .evil.cracker.example.com : deny ftpd : ALL : allow # You need to be clever with finger; do _not_ backfinger!! You can easily # start a "finger war". fingerd : ALL \ : spawn (echo Finger. | \ /usr/bin/mail -s "tcpd\: %...@%h[%a] fingered me!" root) & \ : deny # The rest of the daemons are protected. ALL : ALL \ : severity auth.info \
