Discourse Bad Gateway nach Neustart

Unterstützung Installation
1

Mein Server läuft in einer virtuellen Maschine, die von einem der großen Cloud-Anbieter gehostet wird.
Ich habe discourse erfolgreich darauf installiert, und es lief einen Monat lang einwandfrei.
Heute habe ich beschlossen, die Spezifikationen meiner VM wieder auf die ursprüngliche Konfiguration (*) zurückzusetzen und einen Neustart durchzuführen. Beim Hochfahren lief zwar alles andere auf meinem Server einwandfrei, doch beim Versuch, auf das Discourse-Forum zuzugreifen, erhielt ich einen 502 Bad Gateway-Fehler. Da ich dachte, die Docker-Instanz sei nicht automatisch gestartet, habe ich mich per SSH auf meinen Server verbunden und ./launcher start app ausgeführt. Dabei erhielt ich eine Meldung, dass nicht genügend Speicherplatz verfügbar sei (5 GB verfügbar). Daraufhin habe ich df -h ausgeführt, was anzeigte, dass ich tatsächlich 14 GB verfügbar habe. Also habe ich erneut ./launcher start app ausgeführt, diesmal erhielt ich jedoch eine Warnung, dass Docker Dinge herunterladen werde, und ich sollte Geduld haben. Nach einigen Verarbeitungsschritten erhielt ich die Meldung Nothing to do, your container has already started!. Dennoch lieferten meine Versuche, auf das Forum zuzugreifen, weiterhin den Fehler 502 Bad Gateway.

Nachdem ich mich in diesem Forum informiert hatte, entschied ich mich, ./launcher rebuild app auszuführen. Dabei trat der folgende Fehler auf, der mit PostgreSQL zusammenhängt:

    user@host:[16:48]:/var/discourse# ./launcher rebuild app
    Ensuring launcher is up to date
    Fetching origin
    Launcher is up-to-date
    Stopping old container
    + /usr/bin/docker stop -t 60 app
    app
    cd /pups && git pull && /pups/bin/pups --stdin
    Already up to date.
    I, [2020-07-01T07:19:42.821347 #1]  INFO -- : Loading --stdin
    I, [2020-07-01T07:19:42.831806 #1]  INFO -- : > locale-gen $LANG && update-locale
    I, [2020-07-01T07:19:42.879007 #1]  INFO -- : Generating locales (this might take a while)...
    Generation complete.
    
    I, [2020-07-01T07:19:42.879431 #1]  INFO -- : > mkdir -p /shared/postgres_run
    I, [2020-07-01T07:19:42.885054 #1]  INFO -- :
    I, [2020-07-01T07:19:42.885734 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run
    I, [2020-07-01T07:19:42.891657 #1]  INFO -- :
    I, [2020-07-01T07:19:42.892269 #1]  INFO -- : > chmod 775 /shared/postgres_run
    I, [2020-07-01T07:19:42.898103 #1]  INFO -- :
    I, [2020-07-01T07:19:42.898942 #1]  INFO -- : > rm -fr /var/run/postgresql
    I, [2020-07-01T07:19:42.905607 #1]  INFO -- :
    I, [2020-07-01T07:19:42.906463 #1]  INFO -- : > ln -s /shared/postgres_run /var/run/postgresql
    I, [2020-07-01T07:19:42.912617 #1]  INFO -- :
    I, [2020-07-01T07:19:42.913233 #1]  INFO -- : > socat /dev/null UNIX-CONNECT:/shared/postgres_run/.s.PGSQL.5432 || exit 0 && echo postgres already running stop container ; exit 1
    2020/07/01 07:19:42 socat[26] E connect(6, AF=1 "/shared/postgres_run/.s.PGSQL.5432", 36): No such file or directory
    I, [2020-07-01T07:19:42.925688 #1]  INFO -- :
    I, [2020-07-01T07:19:42.926081 #1]  INFO -- : > rm -fr /shared/postgres_run/.s*
    I, [2020-07-01T07:19:42.931174 #1]  INFO -- :
    I, [2020-07-01T07:19:42.931649 #1]  INFO -- : > rm -fr /shared/postgres_run/*.pid
    I, [2020-07-01T07:19:42.938154 #1]  INFO -- :
    I, [2020-07-01T07:19:42.938850 #1]  INFO -- : > mkdir -p /shared/postgres_run/12-main.pg_stat_tmp
    I, [2020-07-01T07:19:42.943575 #1]  INFO -- :
    I, [2020-07-01T07:19:42.944331 #1]  INFO -- : > chown postgres:postgres /shared/postgres_run/12-main.pg_stat_tmp
    I, [2020-07-01T07:19:42.949159 #1]  INFO -- :
    I, [2020-07-01T07:19:42.961190 #1]  INFO -- : File > /etc/service/postgres/run  chmod: +x  chown:
    I, [2020-07-01T07:19:42.973345 #1]  INFO -- : File > /etc/service/postgres/log/run  chmod: +x  chown:
    I, [2020-07-01T07:19:42.983929 #1]  INFO -- : File > /etc/runit/3.d/99-postgres  chmod: +x  chown:
    I, [2020-07-01T07:19:42.994843 #1]  INFO -- : File > /root/upgrade_postgres  chmod: +x  chown:
    I, [2020-07-01T07:19:42.995487 #1]  INFO -- : > chown -R root /var/lib/postgresql/12/main
    I, [2020-07-01T07:19:44.012812 #1]  INFO -- :
    I, [2020-07-01T07:19:44.013656 #1]  INFO -- : > [ ! -e /shared/postgres_data ] && install -d -m 0755 -o postgres -g postgres /shared/postgres_data && sudo -E -u postgres /usr/lib/postgresql/12/bin/initdb -D /shared/postgres_data || exit 0
    I, [2020-07-01T07:19:44.019545 #1]  INFO -- :
    I, [2020-07-01T07:19:44.019872 #1]  INFO -- : > chown -R postgres:postgres /shared/postgres_data
    I, [2020-07-01T07:19:44.064432 #1]  INFO -- :
    I, [2020-07-01T07:19:44.065186 #1]  INFO -- : > chown -R postgres:postgres /var/run/postgresql
    I, [2020-07-01T07:19:44.071385 #1]  INFO -- :
    I, [2020-07-01T07:19:44.072196 #1]  INFO -- : > /root/upgrade_postgres
    I, [2020-07-01T07:19:44.084004 #1]  INFO -- :
    I, [2020-07-01T07:19:44.084662 #1]  INFO -- : > rm /root/upgrade_postgres
    I, [2020-07-01T07:19:44.090399 #1]  INFO -- :
    I, [2020-07-01T07:19:44.092280 #1]  INFO -- : Replacing data_directory = '/var/lib/postgresql/12/main' with data_directory = '/shared/postgres_data' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.093969 #1]  INFO -- : Replacing (?-mix:#?listen_addresses *=.*) with listen_addresses = '*' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.095204 #1]  INFO -- : Replacing (?-mix:#?synchronous_commit *=.*) with synchronous_commit = $db_synchronous_commit in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.095937 #1]  INFO -- : Replacing (?-mix:#?shared_buffers *=.*) with shared_buffers = $db_shared_buffers in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.096695 #1]  INFO -- : Replacing (?-mix:#?work_mem *=.*) with work_mem = $db_work_mem in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.097554 #1]  INFO -- : Replacing (?-mix:#?default_text_search_config *=.*) with default_text_search_config = '$db_default_text_search_config' in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.101971 #1]  INFO -- : > install -d -m 0755 -o postgres -g postgres /shared/postgres_backup
    I, [2020-07-01T07:19:44.112672 #1]  INFO -- :
    I, [2020-07-01T07:19:44.113831 #1]  INFO -- : Replacing (?-mix:#?max_wal_senders *=.*) with max_wal_senders = $db_max_wal_senders in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.114973 #1]  INFO -- : Replacing (?-mix:#?wal_level *=.*) with wal_level = $db_wal_level in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.116047 #1]  INFO -- : Replacing (?-mix:#?checkpoint_segments *=.*) with checkpoint_segments = $db_checkpoint_segments in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.117033 #1]  INFO -- : Replacing (?-mix:#?logging_collector *=.*) with logging_collector = $db_logging_collector in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.118051 #1]  INFO -- : Replacing (?-mix:#?log_min_duration_statement *=.*) with log_min_duration_statement = $db_log_min_duration_statement in /etc/postgresql/12/main/postgresql.conf
    I, [2020-07-01T07:19:44.119352 #1]  INFO -- : Replacing (?-mix:^#local +replication +postgres +peer$) with local replication postgres  peer in /etc/postgresql/12/main/pg_hba.conf
    I, [2020-07-01T07:19:44.120299 #1]  INFO -- : Replacing (?-mix:^host.*all.*all.*127.*$) with host all all 0.0.0.0/0 md5 in /etc/postgresql/12/main/pg_hba.conf
    I, [2020-07-01T07:19:44.121038 #1]  INFO -- : > HOME=/var/lib/postgresql USER=postgres exec chpst -u postgres:postgres:ssl-cert -U postgres:postgres:ssl-cert /usr/lib/postgresql/12/bin/postmaster -D /etc/postgresql/12/main
    I, [2020-07-01T07:19:44.126334 #1]  INFO -- : > sleep 5
    2020-07-01 07:19:44.157 UTC [49] LOG:  starting PostgreSQL 12.2 (Debian 12.2-2.pgdg100+1) on x86_64-pc-linux-gnu, compiled by gcc (Debian 8.3.0-6) 8.3.0, 64-bit
    2020-07-01 07:19:44.158 UTC [49] LOG:  listening on IPv4 address "0.0.0.0", port 5432
    2020-07-01 07:19:44.158 UTC [49] LOG:  listening on IPv6 address "::", port 5432
    2020-07-01 07:19:44.161 UTC [49] LOG:  listening on Unix socket "/var/run/postgresql/.s.PGSQL.5432"
    2020-07-01 07:19:44.162 UTC [49] FATAL:  could not map anonymous shared memory: Cannot allocate memory
    2020-07-01 07:19:44.162 UTC [49] HINT:  This error usually means that PostgreSQL's request for a shared memory segment exceeded available memory, swap space, or huge pages. To reduce the request size (currently 4423172096 bytes), reduce PostgreSQL's shared memory usage, perhaps by reducing shared_buffers or max_connections.
    2020-07-01 07:19:44.162 UTC [49] LOG:  database system is shut down
    I, [2020-07-01T07:19:49.141762 #1]  INFO -- :
    I, [2020-07-01T07:19:49.142221 #1]  INFO -- : > su postgres -c 'createdb discourse' || true
    createdb: error: could not connect to database template1: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.227852 #1]  INFO -- :
    I, [2020-07-01T07:19:49.228226 #1]  INFO -- : > su postgres -c 'psql discourse -c "create user discourse;"' || true
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.330486 #1]  INFO -- :
    I, [2020-07-01T07:19:49.330822 #1]  INFO -- : > su postgres -c 'psql discourse -c "grant all privileges on database discourse to discourse;"' || true
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.425970 #1]  INFO -- :
    I, [2020-07-01T07:19:49.426356 #1]  INFO -- : > su postgres -c 'psql discourse -c "alter schema public owner to discourse;"'
    psql: error: could not connect to server: could not connect to server: No such file or directory
        Is the server running locally and accepting
        connections on Unix domain socket "/var/run/postgresql/.s.PGSQL.5432"?
    I, [2020-07-01T07:19:49.506638 #1]  INFO -- :
    I, [2020-07-01T07:19:49.507202 #1]  INFO -- : Terminating async processes
    
    
    FAILED
    --------------------
    Pups::ExecError: su postgres -c 'psql discourse -c "alter schema public owner to discourse;"' failed with return #<Process::Status: pid 75 exit 2>
    Location of failure: /pups/lib/pups/exec_command.rb:112:in `spawn'
    exec failed with the params "su postgres -c 'psql $db_name -c \"alter schema public owner to $db_user;\"'"
    eb41679f76cd749ccd8c84a7543365d093619b80df6fc6750b9349fb63565fa1
    ** FAILED TO BOOTSTRAP ** please scroll up and look for earlier error messages, there may be more than one.
    ./discourse-doctor may help diagnose the problem.
    user@host:[17:19]:/var/discourse#

Seltsamerweise führt das Ausführen von ./launcher start app trotz der oben genannten Fehler zu keinen Fehlern:

starting up existing container
+ /usr/bin/docker start app
app

Mit der laufenden Instanz habe ich versucht, ./launcher enter app auszuführen, um in den Container zu gelangen. (Meiner bescheidenen Meinung nach sind die verfügbaren Tools im Container sehr begrenzt – ja, ich bin ein nano-Benutzer und möchte gerne verschiedene Aliase haben; z. B. ll). Ich kann den physischen Pfad zu den Ordnern innerhalb der Docker-Instanz nicht finden (da ich sie gerne mit einem FTP-Client herunterladen würde).

In /var/log/nginx/error.log finde ich für jedes Mal, wenn ich meinen Browser aktualisiere, folgenden Eintrag:

2020/07/01 07:44:16 [error] 646#646: *3 connect() failed (111: Connection refused) while connecting to upstream, client: xxx.xx.0.1, server: _, request: "GET / HTTP/1.1", upstream: "http://127.0.0.1:3000/", host: "discourse.myDomain.com"

Was könnte die Ursache meines Problems sein? Warum funktioniert PostgreSQL plötzlich nicht mehr?

(*) Eine Woche nach der Installation von Discourse habe ich meinen Server mit mehr CPUs und Arbeitsspeicher upgegradet. Das war notwendig, um eine Videokonferenz zu hosten, die ich veranstaltet habe. Nachdem die Konferenz vorbei war, bin ich wieder zu meiner normalen Konfiguration zurückgekehrt. Beachten Sie, dass ich die Festplattengröße während der Änderungen der Spezifikationen zu keinem Zeitpunkt geändert habe.

2

Das liegt daran, dass Ihr aktueller Neuaufbau des Containers fehlgeschlagen ist; Sie starten also eine vorherige Version Ihrer app. Dies ist das normale Verhalten. Wenn ein Neuaufbau nicht erfolgreich ist, wird der ursprüngliche Container im Allgemeinen nicht gelöscht, und das ursprüngliche Image bleibt ebenfalls verfügbar.

In Bezug auf Ihr PG-Problem müssen Sie dem Team weitere Details zu Ihrer App- und Containerkonfiguration liefern, um die bestmögliche Unterstützung zu erhalten.

3

@neounix: Danke.

Ich bin neu in der Verwaltung eines Discourse-Forums und weiß daher nicht genau, wo ich suchen soll und worauf ich achten muss. Ich habe eine im Wesentlichen unveränderte Installation ohne Plugins oder andere Änderungen. In app.yml sind einige Variablen definiert, und ich nutze meinen bestehenden Apache2-Daemon als Reverse-Proxy, um den Discourse-Verkehr über einen separaten VirtualHost an den lokalen Port weiterzuleiten, auf den Discourse konfiguriert ist.

Könntest du bitte näher erläutern, welche Informationen hilfreich wären? Gibt es eine Ressource, die ich lesen könnte, um bei der Fehlersuche zu helfen?

4

Der Kernfehler befindet sich im oben ausgeführten Logfile.

2020-07-01 07:19:44.162 UTC [49] FATAL:  konnte anonyme gemeinsam genutzte Speicherbereiche nicht abbilden: Kann keinen Speicher zuweisen

2020-07-01 07:19:44.162 UTC [49] HINT:  Dieser Fehler bedeutet in der Regel, dass die Anforderung von PostgreSQL nach einem gemeinsam genutzten Speichersegment den verfügbaren Speicher, den Swap-Speicher oder die großen Speicherseiten überschritten hat. Um die Anforderungsgröße (derzeit 4423172096 Bytes) zu verringern, reduzieren Sie die Nutzung des gemeinsam genutzten Speichers durch PostgreSQL, möglicherweise durch Verringerung von shared_buffers oder max_connections.
5

Ich habe diesen Fehler gesehen, habe aber keine Änderungen an der app.yml vorgenommen.
Wo kann ich shared_buffers oder max_connections reduzieren? Sie sind nicht in der app.yml enthalten. Die app.yml enthält nur den Parameter db_shared_buffers, der jedoch auf den Standardwert “4096MB” gesetzt ist, wie schon immer (vor und nachdem ich den Arbeitsspeicher des Servers erhöht habe).

6

Du solltest vielleicht deine Speicherstatistiken posten.

Zum Beispiel unter Linux:

$ free -m
              total        used        free      shared  buff/cache   available
Mem:          64299       12955        9678         361       41664       50265
Swap:          7807          69        7738

Und für Docker-Statistiken, poste die Ausgabe von

docker stats

usw.

Der Fehler hängt mit einem Mangel an Speicher zusammen.

7

Die Server-Speicherstatistiken lauten:

              total        used        free      shared  buff/cache   available
Mem:           3951        2236         414          86        1299        1308
Swap:           511         415          96

Speicherstatistiken nach enter app:

              total        used        free      shared  buff/cache   available
Mem:           3951        2363         321          86        1266        1215
Swap:           511         415          96

Die Ausführung von docker stats > output.txt ergab:

        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT    MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 15.86%              6.48MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT    MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 15.86%              6.48MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.83%               6.539MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.83%               6.539MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 3.30%               6.477MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 3.30%               6.477MiB / 3.859GiB   0.16%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.45%               6.535MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
        CONTAINER ID        NAME                CPU %               MEM USAGE / LIMIT     MEM %               NET I/O             BLOCK I/O           PIDS
       ca4c5f37894c        app                 2.45%               6.535MiB / 3.859GiB   0.17%               20.3kB / 12.6kB     0B / 0B             25
8

Hi @nap

Du kannst viel Speicherplatz freigeben, indem du all diese alten app-Container stoppst und anschließend löschst.

Zum Beispiel:

docker stop <container_id>
docker rm <container_id>

Vorausgesetzt, sie werden nicht verwendet?

Wenn sie alle in Verwendung sind, solltest du in Erwägung ziehen, den Arbeitsspeicher für diesen Server auf über 4 GB zu erhöhen; vielleicht auf 8 GB :slight_smile:

9

Ich habe die App mit ./launcher stop app gestoppt und dann docker stats erneut ausgeführt. Es wurden keine Container aufgelistet. Leider bedeutet mehr Speicher auch höhere Kosten. Das Frustrierende ist gerade, dass es letzten Monat mit 4 GB noch funktioniert hat.

10

Und ich kann im Moment nicht einmal neu aufbauen, was nicht so viel Speicher verbrauchen sollte.

Ohne laufenden Container sehen die Speicherstatistiken so aus:

              total        used        free      shared  buff/cache   available
Mem:           3951        2207         169          91        1574        1332
Swap:           511         446          65

Ich habe einige interessante Verzeichnisse in ./var/lib/docker/overlay2/:

e3e6cdfcc62c2e0b68ec91efxxxxx6c69212c95b5070f7b6b84e97edcb473ea2
64a04d1b97a18f51a5fdc536xxxxxf9473de0c2ccd1a2cc0d62e830164b5f2d8
355303c6af7bebff1163195c5xxxxx8fd1de6333e39adbcb573c7365673b6c85

Kann ich diese löschen?

11

Richtig.

Ich verstehe. Ich war mit einer anderen Aufgabe beschäftigt und habe nicht bemerkt, dass deine Ausgabe die Statistiken für denselben Container anzeigte und nicht für mehrere.

Was sagt dir free -m jetzt, wenn dein Container nicht läuft?

Ich denke, 4 GB RAM sind für einen Container definitiv ausreichend.

12

Nein.

Löschen Sie diese Docker-Dateien nicht.

Das Problem liegt laut Fehlermeldung in Ihrer Discourse-PG-12-Konfiguration. Ich bin mir nicht sicher, wie man das angehen soll, da das Anpassen der PG-12-Konfigurationsdatei für Discourse meiner Meinung nach nicht unterstützt wird.

Die Meta-Top-Experten haben bessere Vorschläge als ich, insbesondere die professionellen Hosting-Teams.

13

Du sagst also, dass dies intern in den Dateien der Docker-Konfiguration liegt? Und dass eine manuelle Änderung Probleme verursachen wird, sobald der Container gestartet oder aktualisiert wird?

14

@nap

Wenn du nach der obigen Fehlermeldung (in Anführungszeichen) bei Google suchst, findest du mehrere direkt relevante Diskussionen zu genau dieser PostgreSQL-Fehlermeldung.

Ich hoffe, das hilft.

15

Haben Sie danach ./discourse-setup erneut ausgeführt oder die Arbeitsspeichereinstellungen in der app.yml manuell geändert? Was bedeuten db_shared_buffers, unicorn_workers und db_work_mem?

Außer dass Sie hinter einem Reverse-Proxy laufen, was die Sache komplizierter macht. Es ist nicht klar, ob der Reverse-Proxy hier schuld ist, aber er erschwert die Diagnose.

Haben Sie mehrere Partitionen? Könnte es sein, dass die Partition, auf der Docker Images erstellt, voll ist?

16

@pfaffman : Danke, dass du dir das angesehen hast.

Nein, ich habe lediglich eine Reihe von Variablendefinitionen hinzugefügt, die sich auf den Situsnamen und die Verwendung von Tags beziehen.

db_shared_buffers ist „4096MB"
unicorn_workers ist 8
db_work_mem ist auskommentiert

Ich habe eine Hauptpartition mit 40 GB (14 GB frei), 512 MB Swap-Speicher und eine 8-GB-Partition für Backups (nicht eingehängt).

Es scheint, als hätte ich das Problem gelöst. Anfangs habe ich versucht, die Puffer auf 2 GB und die Worker auf 4 zu reduzieren, erhielt aber denselben Fehler. Anschließend habe ich die Puffer auf 1 GB reduziert, woraufhin rebuild erfolgreich war und das Forum wieder online ist.

Vielen Dank an alle!!