kafka 磁盤寫滿導致 InternalError

 

tailf kafka/log/server.log

[2019-12-19 17:19:05,121] FATAL (main kafka.server.KafkaServerStartable 116) Fatal error during KafkaServerStartable startup. Prepare to shutdown
java.lang.InternalError: a fault occurred in a recent unsafe memory access operation in compiled Java code
        at kafka.log.FileMessageSet$$anon$1.makeNext(FileMessageSet.scala:264)
        at kafka.log.FileMessageSet$$anon$1.makeNext(FileMessageSet.scala:251)
        at kafka.utils.IteratorTemplate.maybeComputeNext(IteratorTemplate.scala:64)
        at kafka.utils.IteratorTemplate.hasNext(IteratorTemplate.scala:56)
        at kafka.log.LogSegment.recover(LogSegment.scala:179)
        at kafka.log.Log$$anonfun$loadSegments$4.apply(Log.scala:199)
        at kafka.log.Log$$anonfun$loadSegments$4.apply(Log.scala:171)
        at scala.collection.TraversableLike$WithFilter$$anonfun$foreach$1.apply(TraversableLike.scala:733)
        at scala.collection.IndexedSeqOptimized$class.foreach(IndexedSeqOptimized.scala:33)
        at scala.collection.mutable.ArrayOps$ofRef.foreach(ArrayOps.scala:186)
        at scala.collection.TraversableLike$WithFilter.foreach(TraversableLike.scala:732)
        at kafka.log.Log.loadSegments(Log.scala:171)
        at kafka.log.Log.<init>(Log.scala:101)
        at kafka.log.LogManager$$anonfun$loadLogs$2$$anonfun$3$$anonfun$apply$10$$anonfun$apply$1.apply$mcV$sp(LogManager.scala:152)
        at kafka.utils.CoreUtils$$anon$1.run(CoreUtils.scala:56)
        at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
        at java.util.concurrent.FutureTask.run(FutureTask.java:266)
        at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
        at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
        at java.lang.Thread.run(Thread.java:745)

 

看日志查詢資料發現是磁盤滿了。

[kafka@datanode15 kafka]$ du -sh /data11/kafka/
3.4T    /data11/kafka/
[kafka@ngsoc15 kafka]$ df -h
Filesystem      Size  Used Avail Use% Mounted on
devtmpfs        126G     0  126G   0% /dev
/dev/sda2       880G   14G  823G   2% /
/dev/sda1       190M  126M   51M  72% /boot
/dev/sdj        3.6T  2.8T  618G  83% /data09
/dev/sdf        3.6T  2.0T  1.5T  59% /data05
/dev/sdd        3.6T  2.5T  954G  73% /data03
/dev/sdi        3.6T  1.7T  1.8T  50% /data08
/dev/sdk        3.6T  2.4T  1.1T  69% /data10
/dev/sde        3.6T  2.5T  986G  72% /data04
/dev/sdb        3.6T  1.1T  2.4T  32% /data01
/dev/sdg        3.6T  1.4T  2.1T  40% /data06
/dev/sdh        3.6T  2.5T  948G  73% /data07
/dev/sdl        3.6T  3.4T     0 100% /data11
/dev/sdm        3.6T  3.0T  473G  87% /data12
/dev/sdc        3.6T  2.3T  1.2T  66% /data02

 

解決思路：

｛3節點*12盤=36 ; 36/2副本=18分區｝

 

sh bin/kafka-topics.sh --zookeeper zookeeper.host:2181 --alter --topic flow_dns --partition 18

 

* 為什么不直接報IO異常，而是內部錯誤不安全的內存操作？-----來自網絡描述

此錯誤表示或內存訪問導致SIGBUS錯誤，然后被 JVM 捕獲並轉換為異步 。sun.misc.Unsafe.getX()putX()InternalError

更多細節：

sun.misc.Unsafe是 JDK 私有 API，允許直接從 Java 訪問本機內存。此 API 是直接字節緩沖區的基礎，特別是映射字節緩沖區的基礎。
在某些情況下，對文件的內存映射區域的訪問可能會導致 OS 級異常，即 。典型的示例包括：SIGBUS

在基礎文件被截斷后，將訪問內存映射緩沖區。
網絡驅動器上的文件已映射到內存，並且在網絡連接斷開后訪問映射的緩沖區。
嘗試寫入映射到文件系統上的文件的頁面會導致內存不足（默認情況下，空間受總 RAM 的 50% 限制）。tmpfstmpfs
熱點 JVM 無法提前有效地檢測這些問題。它編譯對簡單內存訪問指令的調用。查看內存區域是否有效的其他檢查將過於昂貴。Unsafe.getX / putX

相反，JVM 處理信號。如果它看到調用中發生了錯誤，它將發布到當前線程並繼續執行。SIGBUGUnsafeInternalError
IOException更合適，但 JVM 不能引發它或任何其他異常，因為公共協定不允許其方法引發任何異常。ByteBufferget/put
如果 JIT 編譯方法中的內存訪問失敗，JVM 不會立即引發異常（同樣，對於此類熱字節緩沖區 API 來說，這太貴了）。相反，它將異步發布到當前線程。這意味着錯誤實際上將扔到最近的本機方法或最接近 VM 運行時的調用處。因此，錯誤消息中的"最近"一詞。UnsafeInternalError

 

參考：

https://zh.wikipedia.org/wiki/%E6%80%BB%E7%BA%BF%E9%94%99%E8%AF%AF

https://bugs.openjdk.java.net/browse/JDK-4454115