Dün reddit’te (linux subreddit) dolanırken ilginç bir başlığa denk geldim. Stackoverflow’da açılmış bir konuyla ilgiliydi. “Artık saniye” yüzünden süreçlerin %100 işlemci kullanımına ilişkin ilginç bir sorun idi.
Gece yarısından sonra sunucularda ilginç bir yavaşlamaya tanık oldum, load’a baktığımda ise “ehe” demekten alıkoyamadım kendimi: load 25.00 civarındaydı. (İşletim sistemi olarak Scientific Linux 6.2 var bu arada) Sebebini öğrenmekte ise gecikmedim, java ve passenger süreçleri %100 işlemci kullanıyordu. Nitekim sistem saatine elle müdahale edip daha sonra tekrar ntp çalıştırmak yetti. Süreçler kendine gelmeye başladı tekrar çalıştırdıktan sonra. Ancak duruma göre reboot da gerekebiliyor.
Konuyla ilgili LKML’de şu konu yer alıyor. Java’da “leap second” ile ilgili de şu konuya ulaşabildim. Red Hat’in artık saniyelerle ilgili sayfasında da şu bağlantıyı gördüm yorumlarda. Java uygulaması çalıştırıyorsanız ve bu soruna denk gelmişseniz orada belirtilen çözüm saati sıfırlamak:
date; date `date +"%m%d%H%M%C%y.%S"`; date
Şimdiye kadar problemi sadece Java (jdk6) ve passenger’da tekrarlayabildim ben. Passenger (mod_rails) harici uygulama sunucularında (unicorn tercih ediyorum, test amaçlı da bir adet thin var) böyle bir soruna denk gelmedim ancak tarih sıfırlamak passenger sürecinin kendisine gelmesini sağladı.
Sonuç olarak sıradışı bir Cumartesi gecesi yaşadım. Bir saniyenin etkisi bazı durumlarda ölümcül olabiliyor 
Aynı sorunu debian üzerinde biz de yaşadık. Ancak reboot attık saati sıfırlamak yetmedi.
Debian testing kullanıyorduk bu arada.
Zimbra 7.2.0′da bahsettiğiniz problem ile karşılaştık. Oldukça yüksek bir CPU kullanımı vardı ve “date; date `date +”%m%d%H%M%C%y.%S”`; date” komutunu çalıştırdığımız anda CPU kullanımı düşmeye başladı. Fakat http://is.gd/DVJ9Y0 adresinde belirtildiği gibi ntpd’yi durdurup, ntpdate’ye geçmek daha fazla tesir etti. Zimbra’da bu problemi yaşayanlara, ntpd yerine ntpdate kullanmalarını tavsiye ederim.
Glassfish ile de aynı sorun tekrarlandı, bilgilerinize.