3
我在調查我們的服務問題，該問題無法解析負載下的s3存儲桶名稱。什麼會導致JVM無法解析負載下的DNS？
我講一個c1.medium EC2實例：
[email protected]:/mnt/log# uname -a
Linux ip-10-243-126-111 2.6.35-30-virtual #56-Ubuntu SMP Mon Jul 11 23:41:40 UTC 2011 i686 GNU/Linux
[email protected]:/mnt/log# cat /etc/issue
Ubuntu 10.10 \n \l
[email protected]:/mnt/log# free
total used free shared buffers cached
Mem: 1746008 1681752 64256 0 29600 1582508
-/+ buffers/cache: 69644 1676364
Swap: 917500 32 917468
的應用與-server, jvm build 1.6.0_23-b05, 32bit
行爲，我看到的是網絡通信已開始「行動滑稽」運行，有時插槽超時發生從我們的mongo連接驅動程序，看起來像：
Caused by: java.net.SocketTimeoutException: Read timed out
at java.net.SocketInputStream.socketRead0(Native Method) ~[na:1.6.0_23]
at java.net.SocketInputStream.read(SocketInputStream.java:129) ~[na:1.6.0_23]
at java.io.BufferedInputStream.fill(BufferedInputStream.java:218) ~[na:1.6.0_23]
at java.io.BufferedInputStream.read1(BufferedInputStream.java:258) ~[na:1.6.0_23]
at java.io.BufferedInputStream.read(BufferedInputStream.java:317) ~[na:1.6.0_23]
at org.bson.io.Bits.readFully(Bits.java:35) ~[mongo-java-driver-2.5.3.jar:na]
at org.bson.io.Bits.readFully(Bits.java:28) ~[mongo-java-driver-2.5.3.jar:na]
at com.mongodb.Response.<init>(Response.java:35) ~[mongo-java-driver-2.5.3.jar:na]
at com.mongodb.DBPort.go(DBPort.java:110) ~[mongo-java-driver-2.5.3.jar:na]
at com.mongodb.DBPort.go(DBPort.java:75) ~[mongo-java-driver-2.5.3.jar:na]
at com.mongodb.DBPort.call(DBPort.java:65) ~[mongo-java-driver-2.5.3.jar:na]
at com.mongodb.DBTCPConnector.call(DBTCPConnector.java:201) ~[mongo-java-driver-2.5.3.jar:na]
... 43 common frames omitted
有時會發生以下情況
Caused by: java.net.UnknownHostException: bucket-system.s3.amazonaws.com
at java.net.InetAddress.getAllByName0(InetAddress.java:1158) ~[na:1.6.0_23]
at java.net.InetAddress.getAllByName(InetAddress.java:1084) ~[na:1.6.0_23]
at java.net.InetAddress.getAllByName(InetAddress.java:1020) ~[na:1.6.0_23]
at org.apache.http.impl.conn.DefaultClientConnectionOperator.resolveHostname(DefaultClientConnectionOperator.java:242) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:130) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.conn.AbstractPoolEntry.open(AbstractPoolEntry.java:149) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.conn.AbstractPooledConnAdapter.open(AbstractPooledConnAdapter.java:121) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:562) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:415) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:820) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:754) ~[httpclient-4.1.jar:4.1]
at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:732) ~[httpclient-4.1.jar:4.1]
at com.amazonaws.http.AmazonHttpClient.executeHelper(AmazonHttpClient.java:240) ~[aws-java-sdk-1.2.5.jar:na]
... 48 common frames omitted
這是可重現但不一致的。一旦在機器上啓動加載（50個併發http請求），機器會在正確響應的時間間隔約5分鐘，然後將所有請求的失敗時間縮短到約10秒，然後進行另一個正確響應週期。
什麼會導致此類行爲？是否有任何ulimit或其他系統設置可能會嘗試調整以改善此問題？任何更多的指針來尋找線索？
我懷疑的另一個選擇是亞馬遜（美國東部1區）的基礎設施，我懷疑那裏的路由器在服務上激活某種DoS預防策略，因爲請求幾乎立即從0跳轉到50.經過一段時間後，它穩定在50個併發速率上，此時硬件適應新的流量。牽強？我還沒有發現任何地方提到這種模式。
你可以在你的java.security策略文件中檢查值'networkaddress.cache.ttl'嗎？默認值是永久性地緩存名稱服務查找的結果，但是如果值爲300（= 5分鐘），那麼這可能是您的週期的解釋。 – beny23