Segmentation fault error_log

[maartenvdv737]

Ik heb een groot probleem op mijn server.

Het gaat om een website met een hoge mysql belasting.

Ik heb al de hele week spontane segmentation faults (voor elk proces van 1). Vanaf de eerste segmentation fault loopt de hele server vast en ik moet httpd en mysqld killen, de load laten dalen en dan weer opstarten.

Ik had dit probleem met Mysql-3.23.52. Gisteren 4.0.12 erop gezet, maar het probleem is alleen maar erger geworden.

Error_log:

code:

ar 22 10:40:48 2003] [notice] Apache/1.3.27 (Unix) PHP/4.3.1 
mod_gzip/1.3.19.1a configured -- resuming normal operatio$
[Sat Mar 22 10:40:48 2003] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec)
[Sat Mar 22 10:40:48 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Sat Mar 22 10:41:59 2003] [notice] child pid 32062 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 32006 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31973 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31954 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31943 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31883 exit signal Segmentation fault (11)

Die segmentation faults gaan nu oneindig door. Vaak als het systeem naar KILLALL even tot rust komt, dan zit er een tijdje tussen het starten van apache en mysql voordat de errors weer komen. In dit geval was het meteen weer raak.

Dus:

Mysql 3.23.52
php-4.3.0
apache 1.3.27

Maar ook met:

Mysql 4.0.12
PHP 4.3.1
Apache 1.3.27

Maxclients 1024


my.cnf

code:

# The MySQL server
[mysqld]
port            = 3306
socket          = /var/tmp/mysql.sock
skip-locking
set-variable    = key_buffer=384M
set-variable    = max_allowed_packet=1M
# table_cache was 512
set-variable    = table_cache=1800
set-variable    = sort_buffer=2M
set-variable    = record_buffer=2M
set-variable    = thread_cache=8
# Try number of CPU's*2 for thread_concurrency
set-variable    = thread_concurrency=8
set-variable    = myisam_sort_buffer_size=64M
log-bin
server-id       = 1

Ik maak gebruik van MyIsam tabellen, met alle id's als INDEX. De db is ongeveer 450 Mb groot.


Kan er iets fout zitten in mijn collumns, bijvoorbeeld dat ik bijna geen UNIQUE velden heb?

De server ligt nu de hele tijd plat en echt ALLE suggesties zijn welkom!

[Roelant]

Professional Networking & Servers >> Non-Windows Operating Systems

[pistole]

vergelijk de timestamps eens met je access_log resp. error_log van httpd? Misschien vind je overeenkomsten (i.e. grove fouten in scripts?)

[maartenvdv737]

Dit heb ik gedaan, maar het zijn telkens andere php bestanden die worden aangeroepen.

Nu hebben deze wel allemaal dezelfde includes, maar goed.
Mysql lijkt gewoon de bottleneck te zijn, en nu gaat ie nog veel slechter dan gisteren terwijl ik alleen mysql heb geupdate.

[pistole]

ga anders eens testen via een mysql console; maar een testfile met daarin de queries die je via php zou gaan uitvoeren. Daar even mee gaan stress testen (wel ff je httpd stoppen dan)

[maartenvdv737]

hoe kan ik makkelijk een stress test doen?

code:

 11:43:28 up 10 days, 16:51,  2 users,  load average: 3.36, 1.05, 1.11
238 processes: 229 sleeping, 9 running, 0 zombie, 0 stopped
CPU states:  82.5% user,  16.8% system,   0.0% nice,   0.7% idle
Mem:   2069024K total,  1181936K used,   887088K free,   217564K buffers
Swap:  2097136K total,     5540K used,  2091596K free,   515880K cached

  PID USER     PRI  NI  SIZE  RSS SHARE STAT %CPU %MEM   TIME COMMAND
 1419 mysql     13   0 31724  30M  3264 S    17.3  1.5   0:01 mysqld
 1391 mysql     14   0 31664  30M  3264 S    16.8  1.5   0:33 mysqld
 1403 mysql     13   0 31664  30M  3264 R    16.4  1.5   0:06 mysqld
 1410 mysql     13   0 31664  30M  3264 S    16.2  1.5   0:09 mysqld
 1425 mysql     13   0 31724  30M  3264 S    16.2  1.5   0:01 mysqld
 1433 mysql     10   0 31672  30M  3264 R    16.2  1.5   0:01 mysqld
 1161 mysql     16   0 31604  30M  3264 S    16.0  1.5   0:22 mysqld
 1420 mysql     14   0 31724  30M  3264 R    16.0  1.5   0:01 mysqld
 1388 mysql     11   0 31664  30M  3264 S    15.8  1.5   0:14 mysqld
 1421 mysql     17   0 31724  30M  3264 R    15.4  1.5   0:01 mysqld
 1408 mysql     13   0 31664  30M  3264 S    15.2  1.5   0:06 mysqld
 1406 mysql     14   0 31664  30M  3264 R    15.0  1.5   0:06 mysqld
 1417 mysql     12   0 31720  30M  3264 S    14.8  1.5   0:01 mysqld
 1404 mysql     12   0 31664  30M  3264 R    14.2  1.5   0:05 mysqld

Die load is nog laag, maar loopt binnen no-time naar 600!!!

[moto-moi]

maartenvdv schreef op 22 March 2003 @ 10:51:
Error_log:

code:

[Sat Mar 22 10:41:59 2003] [notice] child pid 32006 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31973 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31954 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31943 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31883 exit signal Segmentation fault (11)

Aj... Segfault 11.. Dat betekend meestal maar 1 ding : brakke hardware
En dat houdt meestal weer in, dat je geheugen brak is. Dat kun je makkelijk testen door memtest86 op te zoeken, en deze te draaien.

[maartenvdv737]

Het is ECC geheugen en heb overlegd met de server beheerder. We weten eigenlijk zeker dat het niet kapot is.

Nu heb ik een log-slow-queries ingesteld en daarin was de volgende query behoorlijk traag:

Querytime=27

PHP:

EXPLAIN SELECT gebruikers.gebruikersnaam
FROM gebruikers
LEFT JOIN gegevens ON gebruikers.id = gegevens.gebruikersID
WHERE DATE_FORMAT( NOW( ) , '%m-%d' ) = FROM_UNIXTIME( geb_datum, '%m-%d' ) 
ORDER BY RAND( ) 
LIMIT 0, 20

EXPLAIN:

table type possible_keys key key_len ref rows Extra
gebruikers ALL NULL NULL NULL NULL 37092 Using temporary; Using filesort
gegevens ref gebruikersID gebruikersID 3 gebruikers.id 1 Using where


Dit lijkt me echter helemaal niet ineffecient, toch??

[moto-moi]

maartenvdv schreef op 22 maart 2003 @ 13:13:
Het is ECC geheugen en heb overlegd met de server beheerder. We weten eigenlijk zeker dat het niet kapot is.

Hoezo weet je dat zeker Dingen kunnen spontaan stuk gaan, en deze foutmelding geeft dat duidelijk aan.

[maartenvdv737]

wat hier stond is opgelost

[ Voor 99% gewijzigd door maartenvdv737 op 24-03-2003 09:53 ]

[elevator]

lees misschien dit eens door.

Wat je misschien het gemakkelijkste kan doen, is een volledige image nemen van je systeem, en de situatie op een ander systeem proberen te reproduceren. Hiermee voorkom je onnodige downtime.

[igmar]

maartenvdv schreef op 22 maart 2003 @ 10:51:
Ik heb een groot probleem op mijn server.

Het gaat om een website met een hoge mysql belasting.

Ik heb al de hele week spontane segmentation faults (voor elk proces van 1). Vanaf de eerste segmentation fault loopt de hele server vast en ik moet httpd en mysqld killen, de load laten dalen en dan weer opstarten.

Ik had dit probleem met Mysql-3.23.52. Gisteren 4.0.12 erop gezet, maar het probleem is alleen maar erger geworden.

Error_log:

code:

ar 22 10:40:48 2003] [notice] Apache/1.3.27 (Unix) PHP/4.3.1 
mod_gzip/1.3.19.1a configured -- resuming normal operatio$
[Sat Mar 22 10:40:48 2003] [notice] suEXEC mechanism enabled (wrapper: /usr/local/apache/bin/suexec)
[Sat Mar 22 10:40:48 2003] [notice] Accept mutex: sysvsem (Default: sysvsem)
[Sat Mar 22 10:41:59 2003] [notice] child pid 32062 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 32006 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31973 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31954 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31943 exit signal Segmentation fault (11)
[Sat Mar 22 10:41:59 2003] [notice] child pid 31883 exit signal Segmentation fault (11)

2 verklaringen :

1) Brakke hardware
2) Een threaded library in PHP gecompiled.

Als alleen Apache d'r last van heeft dat is optie 2 uitermate waarschijnlijk.

[maartenvdv737]

die child pids lijken me van apache idd,

Wat is dat precies die threaded library?
Ben me er niet van bewust dat ik die zelf heb toegevoegd.

Hier de compile opties van php:

code:

CPPFLAGS=-I/usr/local/include
LDFLAGS=-L/usr/local/lib
./configure --prefix=/usr/local \
  --with-apache=/usr/src/Apachetoolbox-1.5.64/apache_1.3.27 \
--enable-exif \
--enable-track-vars \
--with-calendar=shared \
--enable-magic-quotes \
--enable-trans-sid \
--enable-wddx \
--enable-ftp \
--enable-inline-optimization \
--enable-memory-limit \
--with-gd="/usr/local" \
--with-zlib \
--enable-gd-native-tt \
--with-t1lib="/usr" \
--with-jpeg-dir="/usr" \
--with-png-dir="/usr" \
--with-zlib-dir="/usr" \
--with-ttf \
--with-freetype-dir="/usr/local" \
 --with-mcrypt=/usr/local \
 --with-openssl="/usr" \
 --with-gettext="/usr" \
 --with-mysql=/usr/local/mysql \

Is het probleem hiermee misschien op te lossen?

[ Voor 66% gewijzigd door maartenvdv737 op 22-03-2003 16:14 ]

[igmar]

maartenvdv schreef op 22 maart 2003 @ 16:04:
die child pids lijken me van apache idd,

Wat is dat precies die threaded library?

Dat de library in kwestie threads gebruikt om handelingen uit te voeren. PHP is niet 100% threadsafe, en een x aantal extensies moet daarop aangepast worden. Over het algemeen is een threaded library in PHP gebruiken vragen om problemen.

Ben me er niet van bewust dat ik die zelf heb toegevoegd.

Hier de compile opties van php:

<snip compile opties>

Dat is op deze manier niet te zien. Over het algemeen kijk ik door ldd op de httpd bin te draaien, en te kijken of ie gelinked is met libpthread.so. Indien dat niet het geval is dien je die test ook op ALLE .so's te doen die meegelinked zijn.

Het probleem (indien het inderdaad een threaded lib is) is alleen op te lossen door de library te recompilen.

Indien je de oorzaak niet kan vinden zal je terug moeten vallen op gdb en dergelijke tools.

[Kees]

Welke mysql gebruik je? de binary van de mysql site of compileer je zelf wat?

In het tweede geval, welke glibc, en ik zou toch echt de binary gebruiken.

Verder nog wat over je MyISAM tables, deze moet je eigenlijk niet gebruiken voor een database met veel load, myisam gebruikt namelijk tablelevel locking, als ik jou was zou ik over stappen op innodb tables (eens in een nachtje alles laten converteren). Innodb gebruikt rowlevel locking, je kan dan dus meerdere selects uitvoeren op een table.

Verder, wat zegt de 'show processlist', heb je veel queries die 'locked' zijn? dan moet je zeker weten naar innodb overstappen, verder zou ik mysqlstat (http://www.mysqlstat.org/en/) eens instaleren, dan kun je mooi zien of je db wel het geheugen gebruikt, of dat hij bijvoorbeeld allemaal temp tables op de disk moet maken.

Dat hele gepraat over threaded libs etc zegt mij erg weinig, in mijn redelijk ruime ervaring is in dit geval vrijwel altijd mysql de boosdoener, eventueel in combinatie met brakke scripts (pconnects etc zodat je een erg fors aantal connects 'openhoud', of php scripts die je niet genoeg debugged (error_reporting(0)) zodat je de errors niet ziet. Ook zou ik eens controleren of je user wel goed staat, want zo te zien heb je ranzig veel permission denied, gewoon die user+pass pakken in met mysql inloggen en dan kijken of je er uberhaubt wel inkomt.

max connections op 1024 heeft niet eens zoveel zin denk ik, dat zorgt alleen maar voor problemen, mijn ervaring is dat je met 128 per webserver + 128 'overflow' (dus 1 webserver: 256 max_conns, 2 webservers, 378 conns etc) meer dan genoeg hebt, omdat apache in principe (tenzij je in de source loopt te hakken) niet meer dan 256 requests simultaan kan doen, (als je meerdere connecties naar dezelfde db per php script gebruikt, dan zou ik me toch eens achter de oren krabben, want dat is niet nodig )

Verder in je scripts ook opletten of de db connectie wel wordt afgesloten met mysql_close(), nu doet PHP dat zelf ook wel goed, maar het is netter om zelf je troep op te ruimen

[maartenvdv737]

Kees schreef op 22 March 2003 @ 18:00:
Welke mysql gebruik je? de binary van de mysql site of compileer je zelf wat?

In het tweede geval, welke glibc, en ik zou toch echt de binary gebruiken.

Ik gebruik mysql-4.0.12 maar ben nu aan het downgraden terug naar 3.52.56.
Ik compileer vanaf de source, en daarvoor gebruik ik Apachetoolbox(.com)

Glibc 2.2.5 als ik het goed heb.

Verder nog wat over je MyISAM tables, deze moet je eigenlijk niet gebruiken voor een database met veel load, myisam gebruikt namelijk tablelevel locking, als ik jou was zou ik over stappen op innodb tables (eens in een nachtje alles laten converteren). Innodb gebruikt rowlevel locking, je kan dan dus meerdere selects uitvoeren op een table.

Ik was ook langzaam alle tabellen naar innodb aan het omzetten. Maar hielp nog niet echt veel.
Trouwens, dat omzetten gaat toch heel snel? Bij mij wel althans...

Verder, wat zegt de 'show processlist', heb je veel queries die 'locked' zijn? dan moet je zeker weten naar innodb overstappen, verder zou ik mysqlstat (http://www.mysqlstat.org/en/) eens instaleren, dan kun je mooi zien of je db wel het geheugen gebruikt, of dat hij bijvoorbeeld allemaal temp tables op de disk moet maken.

Heb de processlist vaak bekeken, en wel wat slechte queries verwijderd, maar hielp niets in de load. Heb ook de my.cnf aangepast:

code:

[mysqld]
port            = 3306
socket          = /var/tmp/mysql.sock
skip-locking
set-variable    = key_buffer=384M
set-variable    = max_allowed_packet=2M
set-variable    = long_query_time=5
##set-variable    = connect_timeout=30
# table_cache was 512
set-variable    = table_cache=1500
set-variable    = sort_buffer=4M
set-variable    = wait_timeout=30
set-variable    = record_buffer=2M
set-variable    = thread_cache=12
# Try number of CPU's*2 for thread_concurrency
set-variable    = thread_concurrency=8
set-variable    = myisam_sort_buffer_size=64M
set-variable    = max_connections=300
set-variable    = tmp_table_size=100M
log
log-warnings
log-update

Dat hele gepraat over threaded libs etc zegt mij erg weinig, in mijn redelijk ruime ervaring is in dit geval vrijwel altijd mysql de boosdoener, eventueel in combinatie met brakke scripts (pconnects etc zodat je een erg fors aantal connects 'openhoud', of php scripts die je niet genoeg debugged (error_reporting(0)) zodat je de errors niet ziet. Ook zou ik eens controleren of je user wel goed staat, want zo te zien heb je ranzig veel permission denied, gewoon die user+pass pakken in met mysql inloggen en dan kijken of je er uberhaubt wel inkomt.

Ik gebruik geen pconnects, en er zijn ook niet zoveel processen. 300 max. Mysql heeft vaak veel cpu, met een korte Time, maar soms 1 van 6:30 ofzo!
Er zitten geen errors in mijn php_code, misschien wel bugs, maar geen errors.
Die access denied is mij volstrekt onduidelijk. De hele site werkt via een config file en die staat goed (anders zou de site ook niet werken, "voor korte tijd")

Misschien iemand die uit alle macht probeert mijn mysql te hacken?
user is echter alleen localhost

max connections op 1024 heeft niet eens zoveel zin denk ik, dat zorgt alleen maar voor problemen, mijn ervaring is dat je met 128 per webserver + 128 'overflow' (dus 1 webserver: 256 max_conns, 2 webservers, 378 conns etc) meer dan genoeg hebt, omdat apache in principe (tenzij je in de source loopt te hakken) niet meer dan 256 requests simultaan kan doen, (als je meerdere connecties naar dezelfde db per php script gebruikt, dan zou ik me toch eens achter de oren krabben, want dat is niet nodig )

max connections 1024 sloeg op apache, en heeft altijd goed gewerkt, dus laat ik even zo..

Verder in je scripts ook opletten of de db connectie wel wordt afgesloten met mysql_close(), nu doet PHP dat zelf ook wel goed, maar het is netter om zelf je troep op te ruimen

Doe ik inderdaad niet, eigenlijk nooit. Maar zou dit het probleem wel kunnen zijn...

[ Voor 4% gewijzigd door maartenvdv737 op 22-03-2003 18:49 ]

[maartenvdv737]

Op aanraden van kees heb ik de binary geinstalleerd, jammer genoeg heeft dit niets geholpen....

Ik zit nog steeds erg met het feit dat er zoveel "access denied" in mijn logs staan...

[chem]

Die query is trouwens 100% INEFFICIENT!
lees de manual er maar op door, hij is echt volkomen fout

Verder zijn segfaults door PHp scripts vaak te wijten aan brakke code. Niet per se brak geschreven, maar wel zodanig dat PHP de kluts kwijtraakt. Bv. by-reference passing en andere constructies. Al weet ik niet wat (11) precies inhoudt.

[Wilke]

Signal 11 == Segfault. Zie ook het stukje in de NOS FAQ over segfaultende machines. Het kan natuurlijk best aan MySQL liggen, maar om uit te sluiten dat het aan de machine ligt, is het toch echt een goed idee om memtest86 te draaien, vooral als het eerder niet zo was.

Verder: als ik die query snap wil je alle users die vandaag jarig zijn in een random volgorde hebben, right?

Waarom dan niet gewoon:

SELECT usr.gebruikersnaam
FROM gebruikers usr, gegevens geg
WHERE geg.gebruikersID = usr.id
AND DATE_FORMAT( NOW( ) , '%m-%d' ) = FROM_UNIXTIME( usr.geb_datum, '%m-%d' )
ORDER BY RAND( ) 
LIMIT 0, 20

Of doet die query heel iets anders dat ik met mijn ook weer niet al te 13373 SQL-skills over het hoofd zie

Om deze query efficient uit te voeren (als hij vaak uitgevoerd wordt is dat dus wel gewenst...)wil je overigens dat er een index is op 'gegevens.gebruikersID'.

En verder: als die DB groot is, dan geen MyISAM, maar InnoDB tables gebruiken (zie verhaal van Kees).

[igmar]

chem schreef op 22 maart 2003 @ 21:13:
Die query is trouwens 100% INEFFICIENT!
lees de manual er maar op door, hij is echt volkomen fout

Verder zijn segfaults door PHp scripts vaak te wijten aan brakke code. Niet per se brak geschreven, maar wel zodanig dat PHP de kluts kwijtraakt. Bv. by-reference passing en andere constructies. Al weet ik niet wat (11) precies inhoudt.

Dit is vrij zware BS al zeg ik het zelf. Brakke PHP code behoort niet tot sigsegv's te lijden, en indien dat wel gebeurd is het een PHP bug.

De keiharde feiten zeggen dat apache childs die vaak over de zeik gaan gewoon het mixen is van threaded / niet threaded code. Hier zijn al ontelbare threads over geweest op de php-core lijst.

[igmar]

maartenvdv schreef op 22 maart 2003 @ 10:51:
<snip problemen load>

Het volgende 'even' doen :

1) httpd compilen met debug info ,daar is een configure flag voor, en indien die er niet is : export CFLAGS=-g voordat je de configure draait.

2)

gdb /path/naar/httpd
(gdb) set args -X
run

Daarna lekker laten lopen en wachten totdat ie crashed.
Daarna als commando bt

Post daar de uitvoer eens van.

[igmar]

Kees schreef op 22 March 2003 @ 18:00:

<snip verhaal over innodb>

Dat hele gepraat over threaded libs etc zegt mij erg weinig, in mijn redelijk ruime ervaring is in dit geval vrijwel altijd mysql de boosdoener, eventueel in combinatie met brakke scripts (pconnects etc zodat je een erg fors aantal connects 'openhoud', of php scripts die je niet genoeg debugged (error_reporting(0)) zodat je de errors niet ziet. Ook zou ik eens controleren of je user wel goed staat, want zo te zien heb je ranzig veel permission denied, gewoon die user+pass pakken in met mysql inloggen en dan kijken of je er uberhaubt wel inkomt.

Dit behoort volgens mij nog steeds geen sigsegv's te geven. Ik heb m'n collega even gemaild,om even te vragen wat de status is van dat threaded probleem. Aangezien hij in het PHP core team zit heeft ie daar iets meer kijk op.

max connections op 1024 heeft niet eens zoveel zin denk ik, dat zorgt alleen maar voor problemen, mijn ervaring is dat je met 128 per webserver + 128 'overflow' (dus 1 webserver: 256 max_conns, 2 webservers, 378 conns etc) meer dan genoeg hebt, omdat apache in principe (tenzij je in de source loopt te hakken) niet meer dan 256 requests simultaan kan doen, (als je meerdere connecties naar dezelfde db per php script gebruikt, dan zou ik me toch eens achter de oren krabben, want dat is niet nodig )

Verder in je scripts ook opletten of de db connectie wel wordt afgesloten met mysql_close(), nu doet PHP dat zelf ook wel goed, maar het is netter om zelf je troep op te ruimen

Leuk, maar als je daar overheen gaan krijg je een warning, of gewoon helemaal niks, maar geen sigsegv, er even vanuitgaande dat ie geen brakke hardware heeft, wat de problemen overigens ook goed verklaard.

[igmar]

Even voor de volledigheid : krijg je die sigsegv's ook als de load NIET hoog is ??

[maartenvdv737]

dacht even van het probleem af te zijn, toch niet

[ Voor 86% gewijzigd door maartenvdv737 op 24-03-2003 09:54 ]

[maartenvdv737]

Klote, te vroeg gejuicht, het probleem is er nog steeds.

Volgens mij komen de sigsegv's alleen op het moment dat de load wel begint op te lopen, maar is moeilijk te zeggen eigenlijk wat er gebeurd.

Iemand nog suggesties?

[Jelmer]

Oververhitting van onderdelen (geheugen, cpu, chipset) misschien? Heb hier ns een bzip zien segfaulten, omdat mn fan van mn Athlon niet meer draaide.. (ok de rest van het systeem ging daarna snel mee (kernel panic), maar na een minuut of 10 de pc uit gehad te hebben draaide alles weer prima)

[ Voor 33% gewijzigd door Jelmer op 23-03-2003 22:50 ]

[ACM]

* ACM snapt nooit zo goed waarom het eerste waar men aan denkt bij een segmentation fault het corrupte geheugen is
Waarom crashen andere applicaties niet dan?

Als test heb ik ondertussen het compileren van een 2.4 kernel geaccepteerd, een doos van mij had een brak moederbord en daardoor inderdaad een hoeveelheid segfaults. Wat vooral optrad bij compilatie van 2.4 kernels, maar doorgaans ook gevolgd werd door een kernel panic.

Anyway, ter illustratie:

C:

#include <stdio.h>

int main( void )
{
        char i[] = "Help";

        strcpy((char*)(-100), i);

    return 1;
}

Voer dat aan gcc en voer het uit... Levert een segmentation error op en wees maar niet bang, je geheugen is echt niet brak dan ineens hoor

[maartenvdv737]

Segfaults hoef ik niet te reproduceren, die krijg ik vaak genoeg.

Even over innodb, ik heb 76 queries/sec op zijn max. Is dat voldoende lonend om innodb te gebruiken?

Ik heb ook buitensporig veel Com_change_database in mijn SHOW STATUS.

Ik heb het vergeleken met een veel drukkere site en die heeft er nog minder.

Het rare is dat ik in mijn code nergens van database verwissel, en er zowieso maar 3 zijn, waarvan 1 niet gebruikt en 1 de mysql db.....

[ Voor 48% gewijzigd door maartenvdv737 op 24-03-2003 09:54 ]

[ACM]

Wellicht dat je pconnects gebruikt en dat ie daarvoor steeds een select_db als een change-db ziet?

[igmar]

ACM schreef op 23 March 2003 @ 23:11:
* ACM snapt nooit zo goed waarom het eerste waar men aan denkt bij een segmentation fault het corrupte geheugen is
Waarom crashen andere applicaties niet dan?

Omdat niet je gehele geheugen brak is, maar vaak een paar adressen. Je kernel zit op een vaste positie in het geheugen, alleen je applicaties wisselen van plek.

gcc is de perfecte stress-test, gezien het feit dat het intern en en al pointer is.

Als test heb ik ondertussen het compileren van een 2.4 kernel geaccepteerd, een doos van mij had een brak moederbord en daardoor inderdaad een hoeveelheid segfaults. Wat vooral optrad bij compilatie van 2.4 kernels, maar doorgaans ook gevolgd werd door een kernel panic.

Anyway, ter illustratie:

C:

#include <stdio.h>

int main( void )
{
        char i[] = "Help";

        strcpy((char*)(-100), i);

    return 1;
}

Voer dat aan gcc en voer het uit... Levert een segmentation error op en wees maar niet bang, je geheugen is echt niet brak dan ineens hoor

Wat een vergelijking.. Als ik m'n PC een mep geef met een moker is ie ook kapot. Sorry, bovenstaande voorbeeld slaat als een tang op een varken.

code:

int main(void)
{
    char *x = NULL;
    *x = 1234;
    return 0;
}

is overigens sneller, en segfault ook

[ Voor 7% gewijzigd door igmar op 24-03-2003 08:03 ]

[Wilke]

Ja, en als je het dus 99,9999% zeker wilt weten, dan draai je even memtest86. Dat is een vrij kleine moeite, en is hier ook al door verschillende mensen opgemerkt....

Het kan natuurlijk heel goed een bug in MySQL (of ergens anders) zijn die dit veroorzaakt, maar een wat minder stukje geheugen kan het ook veroorzaken. Dus, als dat zo gemakkelijk te testen is, kun je het net zo makkelijk even definitief uitsluiten...

[0siris]

zie ik goed dat die machine een uptime van 12 dagen heeft? Of zit ik de verkeerde machine te nmappen Kun je mooi eens rebooten en memtest86 draaien. En als je dan toch reboot, maak die behuizing eens open en kijk of je koeler nog op je processor zit (bij mij was die er een keer afgeschoten, CPU bloedjeheet, segfaults all over the place)

[maartenvdv737]

Die machine is superstabiel, bij een load van 660 crashed ie nog niet. De segfaults treden nergens anders op, behalve in de error_log van apache.

We zijn nu 99,99999% zeker dat het geheugen goed werkt. Ook hebben we de mysql config vergeleken met drukkere sites. Ook geen duidelijke verschillen.

We gebruiken geen pconnect, dus waar die com_change_db nu op slaat blijft me een raadsel.

Misschien dat er mensen zijn die kunnen aangeven waar code-technisch nog problemen kunnen liggen. Ik maak behoorlijk veel gebruik van indexen, (niet van unique) ik heb vrijveel queries geoptimaliseerd met EXPLAIN.

De meest bezochte pagina's hebben ongeveer 15-20 queries. Misschien is dit teveel van het goede?

Ik heb nu op de drukste pagina's een mysql_close toegevoegd, kijken of dat helpt.


Ik heb even naar mijn database class gekeken, elke pagina maakt een instantie van mijn class aan, waarbij een create_database.php wordt aangeroepen.
Deze doet het volgende:

PHP:

 function create_database($server_name, $database_name, $user_name, $user_password) {

   $this->server_name = $server_name;
   $this->database_name = $database_name;
   $this->user_name = $user_name;
   $this->user_password = $user_password;

   $this->suppress_errors = 1;
   $result = $this->connect();
   $this->suppress_errors = 0;
   $this->connect();

 }

 function connect() {
   $this->connection = @mysql_connect($this->server_name, 
        $this->user_name, $this->user_password);

     if($this->connection == 0)
      $this->print_error("Kan geen verbinding maken met de database.");

   $this->select_database($this->database_name);

   return $this->connection;
 }

 function select_database($db_name) {
   $this->check_connect();

   $result = @mysql_select_db($db_name);

     if(!$result)
      $this->print_error("Kan database (" . $db_name . ") niet selecteren. <br>
      Mysql error: (" . $this->error_string() . ").");
 }

Ik doe dus eigenlijk wel telkens een select_db, misschien dat hij die ziet als een change_db? Kan ik niet zorgen dat hij altijd in dezelfde db zit?

[ Voor 46% gewijzigd door maartenvdv737 op 24-03-2003 10:02 ]

[ACM]

igmar schreef op 24 March 2003 @ 08:01:
Wat een vergelijking.. Als ik m'n PC een mep geef met een moker is ie ook kapot. Sorry, bovenstaande voorbeeld slaat als een tang op een varken.

Dan snap je niet wat ik bedoel...
Ik bedoel daar dat een programmeerfout vrij eenvoudig een segfault oplevert, zonder dat dan direct je geheugen maar rot is ofzo.

Wilke schreef op 24 March 2003 @ 09:04:
Ja, en als je het dus 99,9999% zeker wilt weten, dan draai je even memtest86. Dat is een vrij kleine moeite, en is hier ook al door verschillende mensen opgemerkt....

Niet iedereen kan een productie-server zomaar uit de roulatie halen en er es een testje (van in het ergste geval een paar uur) op doen

En aangezien ik op veel van de servers waar ik apache op draai ook zo nu en dan segfaults zie ga ik niet van al die servers denken dat het geheugen rot is... Ondanks dat lopen de machines wel in de meerdere tientallen dagen uptime, sterker nog je leest deze pagina via zulke machines.
gd-lib is ook zo'n leuke bron van segfaults trouwens, verkeerde url naar een font-bestand levert al een segfault op geloof ik...

[ Voor 7% gewijzigd door ACM op 24-03-2003 15:13 ]

[maartenvdv737]

Tja, dat kan natuurlijk allemaal, maar als er een bug in mijn php code zit die een segfault levert, dan moet je dat kunnen nabootsen door dat bestand aan te roepen en dan moet de server meteen flippen.

De segfaults komen echter alleen als het druk is. Ik ga er vanuit dat niet juist op dat moment iemand een pagina aanroept die verder nooit iemand aanroept.
Het lijkt me dus niet een grove php fout o.i.d.

Misschien dat iemand nog kan reageren op het stukje php hierboven?

Of kan hij verplaatst worden naar /14?

[RvdH]

Je moet zeker weten dat je PHP compileert met de mysql-libs van de versie die je geinstalleerd hebt, en niet de oude versie.. het handigste is gewoon om alle source (muv mysql) te verwijderen, opnieuw te downloaden, en te installeren. Ik heb die fout wel vaker gezien, en die kwam doordat PHP gecompileerd was met verkeerde libs.

[maartenvdv737]

Het probleem begon met een installatie waar apache mysql en php alle 3 correct voor het eerst zijn geinstalleerd.

Daarna ben ik geswitched naar 4.0.12, maar heb daarna netjes weer php en apache geinstalleerd via apacheToolBox. Ook een nieuwere versie van php, dus het lijkt me dat dit geen probleem kan zijn.

[RvdH]

Ik weet haast zeker, dat als je alle apache/php/mysql dingen op je systeem verwijdert (dus ook in /lib en /usr/lib etc) en helemaal opnieuw begint, dat het wel gewoon gaat werken.

Nu kunnen er drie verschillende versies libraries op je systeem staan, en elke keer als ik die fout in mn error log zag, had het te maken met verkeerde libs. Maar als je het zelf beter denkt te weten dan bekijk je het maar .

[maartenvdv737]

Ik wil het best proberen, maar dan wil ik eerst zeker weten dat jij dingen weghaalt die ik niet weghaal:

in de source dir voor elke install die dat ondersteund: make uninstall

dan
rm -rf /usr/local/mysql
rm -rf /usr/local/lib/mysql
rm -rf /usr/local/apache

dan weer installeren.
Welke dingen verwijder jij nog meer?
En hoe ben je erachter gekomen dat het met verkeerde libs te maken had?

[RvdH]

Probeer ook nog een make deinstall in die dirs.
Dan kijk je in je /etc/ld.so.conf, en ga je elke directory na op bestanden die met mysql of php te maken hebben (en die verwijder je), bijvoorbeeld libmysqlclient.so.*. Daarna ga je /lib, /usr/lib, en /usr/local/lib na op diezelfde soort bestanden.

Uiteindelijk doe je gewoon een find / -name *mysql*, en verwijder je de uitkomst (tenzij je zeker weet dat het bestand er niets mee te maken heeft), en een find / -name php, en een find / -name apache, etc, tot je 100% zeker weet dat alle bestanden die te maken hebben met apache, mysql, php, etc weg zijn.

Dan doe je voor de zekerheid een ldconfig om je cache te updaten. Dan mysql installeren (gebruik je binary of source? Als je source gebruikt, wat is je ./configure?), dan Apache (wat is je ./configure?), en dan PHP (./configure?).

Ik ben erachter gekomen door te zien dat de error weg ging na een compleet schone install van apache/mysql/php.

[maartenvdv737]

Hoe zien die sigfaults er bij jou uit?

Bij mij is het niet incidenteel, maar vanaf een bepaald moment elke seconde een stuk of 10...

Ik wil het best proberen namelijk, maar probeer uit te zoeken of we het hier over hetzelfde probleem hebben.

[0siris]

hoe is het nou? begon het net spannend te worden, post er niemand meer

[maartenvdv737]

Ik heb wat indices en queries aangepast, en het probleem treedt nu niet meer op.
Kan echter ook door het mooie weer komen, want het is een stukje rustiger op het moment.

Als het probleem terug komt zal ik deze topic hervatten.

[ Voor 3% gewijzigd door maartenvdv737 op 30-03-2003 10:06 ]

[maartenvdv737]

Goed, het probleem is er dus nog steeds.

Zondag nacht 4:15, na bijna een week zonder problemen, stijgt de load toch weer gestaag totdat het systeem muur vast zit.

Geen nieuwe aanwijzingen dus, behalve dan dat het snachts ook gebeurd...

[ Voor 34% gewijzigd door maartenvdv737 op 31-03-2003 22:02 . Reden: De tijd van de crash klopte toch niet ]

[igmar]

ACM schreef op 24 maart 2003 @ 15:12:
[...]

Dan snap je niet wat ik bedoel...
Ik bedoel daar dat een programmeerfout vrij eenvoudig een segfault oplevert, zonder dat dan direct je geheugen maar rot is ofzo.

PHP is een scripttaal. PHP kent geen pointers. Een segfault veroorzaakt door PHP code is een PHP bug, geen bug in de PHP code (.php) zelf. De meeste PHP bugs die ik gezien heb zijn simpel te reproduceren, en hebben niks met de load te maken.

Niet iedereen kan een productie-server zomaar uit de roulatie halen en er es een testje (van in het ergste geval een paar uur) op doen

En aangezien ik op veel van de servers waar ik apache op draai ook zo nu en dan segfaults zie ga ik niet van al die servers denken dat het geheugen rot is... Ondanks dat lopen de machines wel in de meerdere tientallen dagen uptime, sterker nog je leest deze pagina via zulke machines.
gd-lib is ook zo'n leuke bron van segfaults trouwens, verkeerde url naar een font-bestand levert al een segfault op geloof ik...

Ik draai er ook een X aantal, en ik zie ze ook wel eens. Eens noem ik zelden, en niet bij bosjes tegelijk. Indien dat wel het geval is is het vaak een hardware probleem, of een probleem in de binary zelf (rotte libs, foute compiler).

GD is overigens geen originele versie, maar een fork, hoofdzakelijk omdat er in de originele GD amper ontwikkeling zat.

Voor dit soort testen hoef je geen server plat te leggen, een tweede bak en/of VMWare kan soms ook een goed testmiddel zijn. Indien het probleem alleen op het originele systeem optreedt ga ik toch weer aan hardwareproblemen denken.

Maar zoals gezegd : Zonder debuggen blift het giswerk.

[ Voor 10% gewijzigd door igmar op 31-03-2003 21:19 ]

[maartenvdv737]

Misschien dat iemand hier iets mee kan:

Het enige wat me opvalt is dat er veel errors van GD zijn, maar daar staan geen tijden bij en is dus moeilijk te zeggen hoe die zich in tijd verhouden tot de segfaults.

Hier de aanroepen aan GD:

PHP:

exec("/usr/local/bin/mogrify -geometry $scale $naam");
exec("/usr/local/bin/convert $nieuwe_naam $naam.jpg");

Na het lezen van dit:
Note: If you start a program using this function and want to leave it running in the background, you have to make sure that the output of that program is redirected to a file or some other output stream or else PHP will hang until the execution of the program ends.

Heb ik er van gemaakt:

PHP:

exec("/usr/local/bin/convert $nieuwe_naam $naam.jpg > /dev/null &");

Ik vraag me nu alleen af of dit wel veilig is. Wat nu als iemand dit script heel vaak gaat uitvoeren?

[ Voor 79% gewijzigd door maartenvdv737 op 27-04-2003 20:42 ]

[ggvw]

Weet niet of iemand er iets aan heeft,

bij mij kwamen een tijd terug segfault 11's in m'n apache log
de oorzaak daarvan was een class die ik gemaakt had om sessies op te slaan in mysql

[ Voor 5% gewijzigd door ggvw op 01-04-2003 11:52 ]

[maartenvdv737]

Ik sla geen sessions op in mysql, maar wel als files.

Waar zat het probleem precies, en wat heb je gedaan om het op te lossen?

[ggvw]

Ik had toen in php.ini de session.save_handler in "user" veranderd en een class geschreven die dus de sessies in mysql opsloeg. Apache crachte iedere keer met een segfault 11 als ik session_start() gebruikte.

Had session.save_handler toen weer veranderd in "files" en toen werkte alles weer naar behoren. Heb toen verder niet onderzocht wat nu precies het probleem was.

Maar aangezien jij gewoon je sessies opslaat als files kan het daar niet aan liggen, al zou het misschien geen kwaad kunnen om een keer met je php.ini settings te spelen.

(trouwens al een keer in de "bug-report" database gekeken van php.net?)

edit:

ghe, ik kwam zojuist toevallig dit tegen op php.net:

If you are using PHP >= 4.1.0 with custom session handlers, you MUST ensure your session read function returns a string type even if the session is empty. Returning false or null (as is common) appears to cause a segmentation fault (signal 11) in the web server.

[ Voor 24% gewijzigd door ggvw op 04-04-2003 13:22 ]

[maartenvdv737]

Goed, ik wil dit topic weer open zetten, omdat alles wat erin staat nog klopt, maar de bug weer terug is...

nu heb ik het volgende stukje gevonden op internet:

Apache segfaults when using PHP and mod_log_sql
This occurs if you compiled PHP with MySQL database support. PHP utilizes its internal, bundled MySQL libraries by default. These conflict with the ``real'' MySQL libraries linked by mod_log_sql, causing the segmentation fault.

The solution is to configure PHP to link against the real MySQL libraries and recompile mod_php. Apache will run properly once the modules are all using the same version of the MySQL libraries.

Nu gebruik ik mod_php, maar het is nergens "geinstalleerd" en dus waarschijnlijk statisch ingebakken. (gebruik apachetoolbox)

Iemand een idee of dit het probleem nog kan zijn en hoe het is op te lossen?