mysql mit 4g ram: InnoDB: Error: pthread_create returned 12

[MasterLR]

ich benutze kernel 2.6.8-2-686-smp. wenn ich ich die option innodb_buffer_pool_size nahe der 2gb grenze einstelle, kommt oben genannter fehler.

gibt es eine 2 gb grenze? wenn ja, welche möglichkeiten habe ich trotzdem den speicher zu nutzen?

DANKE

[Salgar]

Hallo,
bei Google habe ich einen Beitrag [1] gefunden, vielleicht hilft der dir ja weiter. Dort hat jemand die selbe Fehlermeldung - nur halt bei Oracle. Grund ist dort eine Beschränkung der Anzahl an Threads bzw. die Stackgröße.

€: Schau dir mal ulimit an bzw. /etc/security/limits.conf.

Salgar

[1] http://www.linuxquestions.org/questions ... 5/4/307239

[MasterLR]

leider scheint das bei mir nicht das problem zu sein... die thread zahl ist realtiv klein (vorallem beim start, wo der fehler auftritt)

habe die stackgrösse verkleinert - was nichts bewirkte....

mich würd interessieren ob ein thread vielleicht nur bis 2 GB benutzen kann? gibt es hier experten zu diesen thema? habe nur beim suchen einer lösung etwas mit glibc und linuxthreads gefunden - allerdings leider keinen direkten hinweis das es eine beschränkung gibt!?

[Salgar]

Hallo MasterLR,
wie ist deine max_memory_size gesetzt?
Bei mir ist die

Code: Alles auswählen

max memory size       (kbytes, -m) unlimited

Wenn das passt kannst du schonmal davon ausgehen, dass die Beschränkung wohl irgendwo im Kernel/glibc, ... ist denke ich.

[MasterLR]

Code: Alles auswählen

# ulimit -a
core file size        (blocks, -c) 0
data seg size         (kbytes, -d) unlimited
file size             (blocks, -f) unlimited
max locked memory     (kbytes, -l) unlimited
max memory size       (kbytes, -m) unlimited
open files                    (-n) 1024
pipe size          (512 bytes, -p) 8
stack size            (kbytes, -s) 8192
cpu time             (seconds, -t) unlimited
max user processes            (-u) unlimited
virtual memory        (kbytes, -v) unlimited

bin schon auch auf der suche in sachen glibc.... allerdings ist es als "Nicht-Kernel/Linux Entwickler" schwer raus zu finden, ob und wo es eine Beschränkung in glibc gibt :-/

[Salgar]

Hm, schreib doch mal ein kleines C-Programm was per malloc große RAM-Mengen alloziert. Der Fehler kommt ja von pthread - also ist das vielleicht nur eine Folgeerscheinung (RAM voll, irgendwas, ... ). Dann kannst du kontrollieren ob es wirklich ein 2 GB Limit gibt pro malloc/Prozess. Ich habe im Archiv einer Mailingliste etwas von 3GB Limit pro Prozess gehört bei 4GB RAM. Leider findet man keine verlässlichen und eindeutigen Infos dazu.

Ich selbst habe leider nicht allzu viel Erfahrung dabei - 2GB RAM sind z.Z. das höchste der Gefühle bei mir

Salgar

[MasterLR]

ich habe keinerlei Linux/C Programmier-Erfahrung - wenn du rein zufällig so ein test C-Programm zur Hand hast, würd ich es gern probieren

PS: find es einwenig schade und merkwürdig, das man mit 4 GB solche "Probleme" hat - vorallem im Server Betrieb sind heute 4 GB nichts besonderes...

[Salgar]

Hallo,
der Mensch ist ja von Natur aus faul - das hier habe ich bei Google gefunden:

Datei: malloctest.c

Code: Alles auswählen

#include <stdio.h>
#include <stdlib.h>

int main() {
        void *buf = malloc ( (size_t) (3000000000u) ); // genau 3 GB
        if (buf==0) printf("oh no\n"); else printf("yeah\n");
        return 0;
};

Übersetzen mit

Code: Alles auswählen

gcc -o malloctest malloctest.c

Ausführen mit

Code: Alles auswählen

./malloctest

Du kannst ja mal ein bisschen mit der Zahl (3000000000) spielen und die Grenzen austesten.

Salgar

[MasterLR]

LOL ich bekomme: keine Berechtigung

ich habe es als root probiert - auch mit weniger RAM... immer das gleiche Ergebnis

[Salgar]

Dann fehlt wohl das Executable-Flag bei den Berechtigungen der erzeugten ausführbaren Datei. Probier mal

Code: Alles auswählen

chmod 700 malloctest

und ruf das Programm anschließend auf. Sollte dann funktionieren.

Salgar

[MasterLR]

nein tut es nicht

auch nur ein einfaches printf erzeugt die Fehlermeldung - merkwürdig!?
habe pakete libc6-dev und gcc installiert - daran was falsch?

[Salgar]

Hm, sehr sehr komisch. Wann kommt die Fehlermeldung? Beim Kompilieren? Beim Ausführen?

Welche Pakete du genau brauchst weiss ich nicht - ich bin normal unter Gentoo zu Hause. Wenn das komplilieren geht müsste das aber eigentlich alles stimmen.

[Salgar]

So, habe das gerade auf meinem Debian-Server probiert - da geht alles einwandfrei:

Code: Alles auswählen

mkdir malloctest
cd malloctest/
echo '#include <stdio.h> 
 #include <stdlib.h> 
 
 int main() { 
         void *buf = malloc ( (size_t) (3000000000u) ); // genau 3 GB 
         if (buf==0) printf("oh no\n"); else printf("yeah\n"); 
         return 0; 
 };' > malloctest.c
gcc -o malloctest malloctest.c
./malloctest

Ausgabe: oh no

[MasterLR]

oh sorry!!!! ich habe geschlafen!!!! habe mich auf ein verzeichnis zweig bewegt in dem das ausführen per mount option deaktiviert ist

also: 3gb funktionieren nicht - 2,5 gb auch nicht -> 2 gb funktionieren.... nun die frage - was die grenze festlegt und kann ich diese ändern - wenn ja wie!?

[MasterLR]

komme der sache anscheinend näher

Code: Alles auswählen

ipcs -l

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (pages) = 2097152
min seg size (bytes) = 1
...

wenn ich nun

Code: Alles auswählen

echo "3097152" > /proc/sys/kernel/shmall

ausführe, ändert sich der wert

Code: Alles auswählen

ipcs -l

------ Shared Memory Limits --------
max number of segments = 4096
max seg size (kbytes) = 32768
max total shared memory (pages) = 3097152
min seg size (bytes) = 1
...

nun kann ich das test programm mit 3GB erfolgreich laufen lassen -> frage ist nun: kann ich diesen wert so wie oben gefahrlos ändern?

[Salgar]

2GB ist wohl wirklich eine Grenze in der glibc, genauer bei malloc.

Mehr dazu findest du hier: http://www.daimi.au.dk/~kasperd/comp.os ... APPED_BASE

How do I use more than 2GB of virtual memory in one process?
The only real solution to your problem is using a 64bit architecture, but there are workarounds that will help you. [...]

€: Habe deinen Beitrag nicht gelesen gehabt.
Das ist wohl das, was oben im howto als Workaround bezeichnet wird

[MasterLR]

2GB ist wohl wirklich eine Grenze in der glibc, genauer bei malloc.

Mehr dazu findest du hier: http://www.daimi.au.dk/~kasperd/comp.os ... APPED_BASE

How do I use more than 2GB of virtual memory in one process?
The only real solution to your problem is using a 64bit architecture, but there are workarounds that will help you. [...]

siehe mein letzten beitrag

[Salgar]

Keine Ahnung ob man den Wert gefahrenlos ändern kann.
Du kannst ihn anscheinend aber über die Datei /etc/sysctl.conf permanent ändern.

Code: Alles auswählen

kernel.shmall = 2097152 

[MasterLR]

leider stell ich gerad fest, das mysqld trotzdem nicht läuft - es bleibt bei den gleichen fehler!?

[Salgar]

Hm, was steht denn genau im Log? Sind vor der Meldung evtl. Warnungen ausgegeben worden?

[MasterLR]

Code: Alles auswählen

mysqld[2595]: InnoDB: Error: pthread_create returned 12

ich glaube es liegt wirklich an den shared memory zeugs

nur komisch das er sich mit den entsprechenden parametern nicht "überreden" lässt :-/

[feltel]

Der mysqld wird gegen die Standardeinstellungen compiliert sein und die daher benutzen. Ich hatte vor ein paar Jahren ein ähnliches Problem mit Squid und Max-Open-Files. Das ließ sich nur umgehen indem man den Wert via /proc hochsetzte und dann den Squid neu compilierte.

[MasterLR]

zurzeit kann ich mysql nicht kompilieren (fehlende zeit -> noch nie gemacht).... bevor ich diese monströse aufgabe angehen würde - wäre ich gern sicher das es daran liegt *ggg*

könnte man das eigentlich in einer vmware simulieren -> in dieser gäbe es nicht echte 4gb ram (da vmware auf arbeitsmaschine läuft) aber wenn ich genügend swap bereitstellen würde - müsste das doch gehen oder?

hat jemand erfahrung beim kompilieren von mysqld? kann mir jemand sagen _wie_ aufwendig die sache ist? alles mit debian bordmittel möglich? ich müsste es in vmware bzw. einer anderen maschine kompilieren als direkt auf server (schon allein aus sicherheitsgründen)

[feltel]

Stell sicher das deb-src-Einträge in der /etc/apt/sources.list vorhanden sind und dann mach einfach ein

Code: Alles auswählen

apt-get install build-essential
apt-get build-dep mysql-server
apt-get -b source mysql-server

Nach ner ganzen Weile sollte dann ein mysql-server-VERSION.deb entstehen.

[MasterLR]

Stell sicher das deb-src-Einträge in der /etc/apt/sources.list vorhanden sind und dann mach einfach ein

Code: Alles auswählen

apt-get install build-essential
apt-get build-dep mysql-server
apt-get -b source mysql-server

Nach ner ganzen Weile sollte dann ein mysql-server-VERSION.deb entstehen.

also wenn das so einfach geht - denn fall ich vom stuhl
und ich glaub ich werde mich in debian verlieben *gggg*

habe vor jahren ein paar sachen unter linux (nicht debian) kompiliert und es war grausam