Logblock: [Lookup] Fehler beim Schreiben der Datei '/tmp', (Errcode: 28 - No space left on device)

Erstellt am 25. März 2014  ·  3Kommentare  ·  Quelle: LogBlock/LogBlock

Logblock-Entwickler 223.

[16:26:13] [Craft Scheduler Thread - 201/ERROR]: [Lookup] SELECT date, replaced, type, data, playername, x, y, z, signtext FROM `lb-world` INNER JOIN `lb-players` USING (playerid) LEFT JOIN `lb-world-sign` USING (id) WHERE type != replaced ORDER BY date DESC, id DESC : 
java.sql.SQLException: Error writing file '/tmp/MYhXevGe' (Errcode: 28 - No space left on device)
    at com.mysql.jdbc.SQLError.createSQLException(SQLError.java:1073) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.checkErrorPacket(MysqlIO.java:3593) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.nextRowFast(MysqlIO.java:1566) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.nextRow(MysqlIO.java:1422) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.readSingleRowSet(MysqlIO.java:2902) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.getResultSet(MysqlIO.java:476) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.readResultsForQueryOrUpdate(MysqlIO.java:2608) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.readAllResults(MysqlIO.java:1784) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.MysqlIO.sqlQueryDirect(MysqlIO.java:2198) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2620) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.ConnectionImpl.execSQL(ConnectionImpl.java:2570) ~[spigot.jar:git-Spigot-1351]
    at com.mysql.jdbc.StatementImpl.executeQuery(StatementImpl.java:1474) ~[spigot.jar:git-Spigot-1351]
    at de.diddiz.LogBlock.CommandsHandler$CommandLookup.run(CommandsHandler.java:418) [LogBlock.jar:?]
    at org.bukkit.craftbukkit.v1_7_R2.scheduler.CraftTask.run(CraftTask.java:58) [spigot.jar:git-Spigot-1351]
    at org.bukkit.craftbukkit.v1_7_R2.scheduler.CraftAsyncTask.run(CraftAsyncTask.java:53) [spigot.jar:git-Spigot-1351]
    at java.util.concurrent.ThreadPoolExecutor.runWorker(Unknown Source) [?:1.8.0_20-ea]
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) [?:1.8.0_20-ea]
    at java.lang.Thread.run(Unknown Source) [?:1.8.0_20-ea]

Wenn ich den Speicherplatz mit „df -h“ überprüfe, habe ich 176 GB auf meinem Hauptlaufwerk verfügbar, 16 GB verfügbar für „tmpfs“, 1,8 GB von 2 GB verfügbar für „/temp“ und 1,9 GB von 2 GB verfügbar für „/var/“. temp', auf meinem dedizierten Knoten. Wie kommt es zu „Kein Platz mehr auf dem Gerät“? Meine Logblock-Datenbank für MySQL ist 2,4 GB groß.

Hilfreichster Kommentar

Der genaue Fehler ist, dass es nicht in /tmp schreiben kann, weil dort, wo /tmp gemountet ist, kein Platz vorhanden ist. In einigen Linux-Distributionen wird /tmp als tmpfs (Ramdisk) gemountet, sodass Sie selbst dann, wenn Ihre Festplatte über ausreichend Speicherplatz verfügt, einen „no space“-Fehler erhalten können, wenn Sie versuchen, dort zu viel zu schreiben.

Aus dem Stack-Trace sieht es so aus, als wäre dies während eines Lookups (oder Lookup-and-Rollback) passiert - wenn der Lookup entweder viele Daten zurückgegeben oder möglicherweise sogar nur viele Daten durchsucht hat, könnten große temporäre Dateien erstellt werden .

Mögliche Lösungen sind, MySQL ein anderes Temp-Verzeichnis verwenden zu lassen oder tmpfs nicht für /tmp zu verwenden

Alle 3 Kommentare

tmpfs wird komplett im ram gespeichert. Wenn der System-RAM knapp wird, geht tmpfs der Speicherplatz aus.

Aber der Fehler hängt nicht mit tmpfs zusammen?

Der genaue Fehler ist, dass es nicht in /tmp schreiben kann, weil dort, wo /tmp gemountet ist, kein Platz vorhanden ist. In einigen Linux-Distributionen wird /tmp als tmpfs (Ramdisk) gemountet, sodass Sie selbst dann, wenn Ihre Festplatte über ausreichend Speicherplatz verfügt, einen „no space“-Fehler erhalten können, wenn Sie versuchen, dort zu viel zu schreiben.

Aus dem Stack-Trace sieht es so aus, als wäre dies während eines Lookups (oder Lookup-and-Rollback) passiert - wenn der Lookup entweder viele Daten zurückgegeben oder möglicherweise sogar nur viele Daten durchsucht hat, könnten große temporäre Dateien erstellt werden .

Mögliche Lösungen sind, MySQL ein anderes Temp-Verzeichnis verwenden zu lassen oder tmpfs nicht für /tmp zu verwenden

War diese Seite hilfreich?
0 / 5 - 0 Bewertungen

Verwandte Themen

bobhenl picture bobhenl  ·  5Kommentare

laa picture laa  ·  3Kommentare

CeccoCQ picture CeccoCQ  ·  3Kommentare

pankai picture pankai  ·  3Kommentare

Kasendwa picture Kasendwa  ·  3Kommentare