Je suis en train de faire des petits benches sans prétention sur ma
nouvelle machine sous FreeBSD.
J'ai un script qui fait varier les paramètres, et lance des benches
"super-smack" contre le serveur mysqld local.
J'ai deux disques en RAID 1 avec une partition en UFS (20 Go), et une
partition en ZFS (890 Go).
Une carte RAID dont je peux faire varier les paramètres de write cache
(on ou off), et de politique (protection, balance, performance) quand le
cache est activé.
Le script règle les paramètres, lance super-smack, change les
paramètres, relance mysqld, lance super-smack, ad lib.
Au bout de quelques boucles, j'obtiens ceci :
super-smack: Error creating semaphore errno = 28, error is No space left
on device
et super-smack ne parvient plus a rien. Les partitions sont quasiment
vides, donc l'espace disponible n'est pas le facteur vraiment bloquant.
J'ai du rebooter la machine pour que super-smack fonctionne à nouveau.
une piste ?
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
super-smack: Error creating semaphore errno = 28, error is No space left on device
Peut être tu as créé beaucoup de sémaphores et ça bloque. Tu peux voir ça avec ipcs.
Il est possible que l'autre message ne corresponde en fait à rien.
-- Michel Talon
patpro ~ patrick proniewski
In article <4ca506e7$0$27686$, Michel Talon wrote:
patpro ~ patrick proniewski wrote:
> > super-smack: Error creating semaphore errno = 28, error is No space left > on device
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel s 65537 1937850441 --rw-rw-rw- root wheel s 65538 1937850482 --rw-rw-rw- root wheel s 65539 1937850523 --rw-rw-rw- root wheel s 65540 1937850564 --rw-rw-rw- root wheel s 65541 1937850688 --rw-rw-rw- root wheel s 65542 1937850732 --rw-rw-rw- root wheel s 65543 1937850776 --rw-rw-rw- root wheel s 65544 1937850820 --rw-rw-rw- root wheel s 65545 1937850947 --rw-rw-rw- root wheel #
J'ai relancé le script après avoir rebooté, et il m'a refait le même coup au moment d'attaquer la seconde boucle sur ZFS+compression. Et comme la dernière fois, super-smack refait immédiatement l'erreur si je le relance sans avoir rebooté la machine.
J'ai à nouveau rebooté, après avoir sauver la sortie de sysctl -a, que j'ai comparé à celle de l'après-boot sans rien trouver de bien parlant. Il y'a trop de variables dont j'ignore la signification. J'ai quand même un doute sur les vnodes :
Avant le reboot j'ai : kern.maxvnodes: 100000 kern.minvnodes: 25000 vfs.freevnodes: 24983 vfs.wantfreevnodes: 25000 vfs.numvnodes: 66144
Je vais tenter dans la journée de monter kern.maxvnodes à 200000 et de relancer mon script pour voir si il va plus loin. Mais bon, c'est plus du bricolage à l'aveugle là.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <4ca506e7$0$27686$426a34cc@news.free.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
patpro ~ patrick proniewski wrote:
>
> super-smack: Error creating semaphore errno = 28, error is No space left
> on device
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le
message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s
Semaphores:
T ID KEY MODE OWNER GROUP
s 65536 1937850369 --rw-rw-rw- root wheel
s 65537 1937850441 --rw-rw-rw- root wheel
s 65538 1937850482 --rw-rw-rw- root wheel
s 65539 1937850523 --rw-rw-rw- root wheel
s 65540 1937850564 --rw-rw-rw- root wheel
s 65541 1937850688 --rw-rw-rw- root wheel
s 65542 1937850732 --rw-rw-rw- root wheel
s 65543 1937850776 --rw-rw-rw- root wheel
s 65544 1937850820 --rw-rw-rw- root wheel
s 65545 1937850947 --rw-rw-rw- root wheel
#
J'ai relancé le script après avoir rebooté, et il m'a refait le même
coup au moment d'attaquer la seconde boucle sur ZFS+compression. Et
comme la dernière fois, super-smack refait immédiatement l'erreur si je
le relance sans avoir rebooté la machine.
J'ai à nouveau rebooté, après avoir sauver la sortie de sysctl -a, que
j'ai comparé à celle de l'après-boot sans rien trouver de bien parlant.
Il y'a trop de variables dont j'ignore la signification. J'ai quand même
un doute sur les vnodes :
Avant le reboot j'ai :
kern.maxvnodes: 100000
kern.minvnodes: 25000
vfs.freevnodes: 24983
vfs.wantfreevnodes: 25000
vfs.numvnodes: 66144
Je vais tenter dans la journée de monter kern.maxvnodes à 200000 et de
relancer mon script pour voir si il va plus loin. Mais bon, c'est plus
du bricolage à l'aveugle là.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
In article <4ca506e7$0$27686$, Michel Talon wrote:
patpro ~ patrick proniewski wrote:
> > super-smack: Error creating semaphore errno = 28, error is No space left > on device
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel s 65537 1937850441 --rw-rw-rw- root wheel s 65538 1937850482 --rw-rw-rw- root wheel s 65539 1937850523 --rw-rw-rw- root wheel s 65540 1937850564 --rw-rw-rw- root wheel s 65541 1937850688 --rw-rw-rw- root wheel s 65542 1937850732 --rw-rw-rw- root wheel s 65543 1937850776 --rw-rw-rw- root wheel s 65544 1937850820 --rw-rw-rw- root wheel s 65545 1937850947 --rw-rw-rw- root wheel #
J'ai relancé le script après avoir rebooté, et il m'a refait le même coup au moment d'attaquer la seconde boucle sur ZFS+compression. Et comme la dernière fois, super-smack refait immédiatement l'erreur si je le relance sans avoir rebooté la machine.
J'ai à nouveau rebooté, après avoir sauver la sortie de sysctl -a, que j'ai comparé à celle de l'après-boot sans rien trouver de bien parlant. Il y'a trop de variables dont j'ignore la signification. J'ai quand même un doute sur les vnodes :
Avant le reboot j'ai : kern.maxvnodes: 100000 kern.minvnodes: 25000 vfs.freevnodes: 24983 vfs.wantfreevnodes: 25000 vfs.numvnodes: 66144
Je vais tenter dans la journée de monter kern.maxvnodes à 200000 et de relancer mon script pour voir si il va plus loin. Mais bon, c'est plus du bricolage à l'aveugle là.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
patpro ~ Patrick Proniewski
In article , DeVice wrote:
Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace si tu préfères, dans les ports) te donnerait plus de précisions sur ce qui bloque réellement ?
C'est artillerie lourde, et j'aurai bien du mal à tout suivre. On parle de boucles qui génèrent jusqu'à 80 process concurrents. Cela dit, une fois que super-smack ne veut plus se lancer, je pourrai tracer une seule instance facilement.
J'ai suivi les variables relatives aux vnodes du reboot au plantage de mon script sans pouvoir faire de corrélation, je ne vais donc pas toucher au kern.maxvnodes. Là, le script est lancé à nouveau, et je dump tout sysctl -a dans un fichier texte jusqu'au plantage. Après un coup de gnuplot et je verrai si je peux isoler visuellement un paramètre qui sort des clous ou tape une limite au moment où super-smack ne fonctionne plus.
Arrivé à ce stade je lancerai un trace ou un truss pour voir ce qu'il se passe.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <j3ngn7-leu1.ln1@deuxvis.fr>, DeVice <dev.null@deuxvis.fr>
wrote:
Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace
si tu préfères, dans les ports) te donnerait plus de précisions sur ce
qui bloque réellement ?
C'est artillerie lourde, et j'aurai bien du mal à tout suivre. On parle
de boucles qui génèrent jusqu'à 80 process concurrents.
Cela dit, une fois que super-smack ne veut plus se lancer, je pourrai
tracer une seule instance facilement.
J'ai suivi les variables relatives aux vnodes du reboot au plantage de
mon script sans pouvoir faire de corrélation, je ne vais donc pas
toucher au kern.maxvnodes.
Là, le script est lancé à nouveau, et je dump tout sysctl -a dans un
fichier texte jusqu'au plantage. Après un coup de gnuplot et je verrai
si je peux isoler visuellement un paramètre qui sort des clous ou tape
une limite au moment où super-smack ne fonctionne plus.
Arrivé à ce stade je lancerai un trace ou un truss pour voir ce qu'il se
passe.
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace si tu préfères, dans les ports) te donnerait plus de précisions sur ce qui bloque réellement ?
C'est artillerie lourde, et j'aurai bien du mal à tout suivre. On parle de boucles qui génèrent jusqu'à 80 process concurrents. Cela dit, une fois que super-smack ne veut plus se lancer, je pourrai tracer une seule instance facilement.
J'ai suivi les variables relatives aux vnodes du reboot au plantage de mon script sans pouvoir faire de corrélation, je ne vais donc pas toucher au kern.maxvnodes. Là, le script est lancé à nouveau, et je dump tout sysctl -a dans un fichier texte jusqu'au plantage. Après un coup de gnuplot et je verrai si je peux isoler visuellement un paramètre qui sort des clous ou tape une limite au moment où super-smack ne fonctionne plus.
Arrivé à ce stade je lancerai un trace ou un truss pour voir ce qu'il se passe.
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
DeVice
patpro ~ patrick proniewski a écrit :
In article <4ca506e7$0$27686$, Michel Talon wrote:
patpro ~ patrick proniewski wrote:
super-smack: Error creating semaphore errno = 28, error is No space left on device
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel s 65537 1937850441 --rw-rw-rw- root wheel s 65538 1937850482 --rw-rw-rw- root wheel s 65539 1937850523 --rw-rw-rw- root wheel s 65540 1937850564 --rw-rw-rw- root wheel s 65541 1937850688 --rw-rw-rw- root wheel s 65542 1937850732 --rw-rw-rw- root wheel s 65543 1937850776 --rw-rw-rw- root wheel s 65544 1937850820 --rw-rw-rw- root wheel s 65545 1937850947 --rw-rw-rw- root wheel #
J'ai relancé le script après avoir rebooté, et il m'a refait le même coup au moment d'attaquer la seconde boucle sur ZFS+compression. Et comme la dernière fois, super-smack refait immédiatement l'erreur si je le relance sans avoir rebooté la machine.
J'ai à nouveau rebooté, après avoir sauver la sortie de sysctl -a, que j'ai comparé à celle de l'après-boot sans rien trouver de bien parlant. Il y'a trop de variables dont j'ignore la signification. J'ai quand même un doute sur les vnodes :
Avant le reboot j'ai : kern.maxvnodes: 100000 kern.minvnodes: 25000 vfs.freevnodes: 24983 vfs.wantfreevnodes: 25000 vfs.numvnodes: 66144
Je vais tenter dans la journée de monter kern.maxvnodes à 200000 et de relancer mon script pour voir si il va plus loin. Mais bon, c'est plus du bricolage à l'aveugle là.
patpro
Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace si tu préfères, dans les ports) te donnerait plus de précisions sur ce qui bloque réellement ?
-- /dev/full
patpro ~ patrick proniewski a écrit :
In article <4ca506e7$0$27686$426a34cc@news.free.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
patpro ~ patrick proniewski wrote:
super-smack: Error creating semaphore errno = 28, error is No space left
on device
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le
message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s
Semaphores:
T ID KEY MODE OWNER GROUP
s 65536 1937850369 --rw-rw-rw- root wheel
s 65537 1937850441 --rw-rw-rw- root wheel
s 65538 1937850482 --rw-rw-rw- root wheel
s 65539 1937850523 --rw-rw-rw- root wheel
s 65540 1937850564 --rw-rw-rw- root wheel
s 65541 1937850688 --rw-rw-rw- root wheel
s 65542 1937850732 --rw-rw-rw- root wheel
s 65543 1937850776 --rw-rw-rw- root wheel
s 65544 1937850820 --rw-rw-rw- root wheel
s 65545 1937850947 --rw-rw-rw- root wheel
#
J'ai relancé le script après avoir rebooté, et il m'a refait le même
coup au moment d'attaquer la seconde boucle sur ZFS+compression. Et
comme la dernière fois, super-smack refait immédiatement l'erreur si je
le relance sans avoir rebooté la machine.
J'ai à nouveau rebooté, après avoir sauver la sortie de sysctl -a, que
j'ai comparé à celle de l'après-boot sans rien trouver de bien parlant.
Il y'a trop de variables dont j'ignore la signification. J'ai quand même
un doute sur les vnodes :
Avant le reboot j'ai :
kern.maxvnodes: 100000
kern.minvnodes: 25000
vfs.freevnodes: 24983
vfs.wantfreevnodes: 25000
vfs.numvnodes: 66144
Je vais tenter dans la journée de monter kern.maxvnodes à 200000 et de
relancer mon script pour voir si il va plus loin. Mais bon, c'est plus
du bricolage à l'aveugle là.
patpro
Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace
si tu préfères, dans les ports) te donnerait plus de précisions sur ce
qui bloque réellement ?
In article <4ca506e7$0$27686$, Michel Talon wrote:
patpro ~ patrick proniewski wrote:
super-smack: Error creating semaphore errno = 28, error is No space left on device
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel s 65537 1937850441 --rw-rw-rw- root wheel s 65538 1937850482 --rw-rw-rw- root wheel s 65539 1937850523 --rw-rw-rw- root wheel s 65540 1937850564 --rw-rw-rw- root wheel s 65541 1937850688 --rw-rw-rw- root wheel s 65542 1937850732 --rw-rw-rw- root wheel s 65543 1937850776 --rw-rw-rw- root wheel s 65544 1937850820 --rw-rw-rw- root wheel s 65545 1937850947 --rw-rw-rw- root wheel #
J'ai relancé le script après avoir rebooté, et il m'a refait le même coup au moment d'attaquer la seconde boucle sur ZFS+compression. Et comme la dernière fois, super-smack refait immédiatement l'erreur si je le relance sans avoir rebooté la machine.
J'ai à nouveau rebooté, après avoir sauver la sortie de sysctl -a, que j'ai comparé à celle de l'après-boot sans rien trouver de bien parlant. Il y'a trop de variables dont j'ignore la signification. J'ai quand même un doute sur les vnodes :
Avant le reboot j'ai : kern.maxvnodes: 100000 kern.minvnodes: 25000 vfs.freevnodes: 24983 vfs.wantfreevnodes: 25000 vfs.numvnodes: 66144
Je vais tenter dans la journée de monter kern.maxvnodes à 200000 et de relancer mon script pour voir si il va plus loin. Mais bon, c'est plus du bricolage à l'aveugle là.
patpro
Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace si tu préfères, dans les ports) te donnerait plus de précisions sur ce qui bloque réellement ?
-- /dev/full
patpro ~ Patrick Proniewski
In article , patpro ~ Patrick Proniewski wrote:
In article , DeVice wrote:
> Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace > si tu préfères, dans les ports) te donnerait plus de précisions sur ce > qui bloque réellement ?
Bon alors voilà, avec un petit truss rapide :
# truss super-smack update-select.smack 2 10000 2>&1| grep -C2 ERR#25 munmap(0x80107d000,1585152) = 0 (0x0) open("update-select.smack",O_RDONLY,0666) = 2 (0x2) ioctl(2,TIOCGETA,0xffffdef0) ERR#25 'Inappropriate ioctl for device' fstat(2,{ mode=-rw-r--r-- ,inode0671,size527,blksize384 }) = 0 (0x0) read(2,"// this is will be used in the t"...,16384) = 3527 (0xdc7) -- stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inodeX8848,size27,blksize384 }) = 0 (0x0) open("/etc/nsswitch.conf",O_RDONLY,0666) = 3 (0x3) ioctl(3,TIOCGETA,0xffffda00) ERR#25 'Inappropriate ioctl for device' fstat(3,{ mode=-rw-r--r-- ,inodeX8848,size27,blksize384 }) = 0 (0x0) read(3,"#n# nsswitch.conf(5) - name ser"...,16384) = 327 (0x147) -- access("/usr/lib/nss_dns.so.1",0) ERR#2 'No such file or directory' sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) ioctl(3,TIOCGETA,0xffffda10) ERR#25 'Inappropriate ioctl for device' close(3) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|S IGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) -- close(3) = 0 (0x0) fork() = 21821 (0x553d) ioctl(2,TIOCGETA,0xffffdf00) ERR#25 'Inappropriate ioctl for device' wait4(0x553d,0x0,0x0,0x0,0x4,0x1) = 21821 (0x553d) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|S IGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
Je dois bien avouer, ça m'aide pas plus. J'ai cherché un peu autour de TIOCGETA et ioctl, mais sans trouver quelque chose qui me parle vraiment.
des idées ?
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
In article <patpro-D4BFAE.11592401102010@localhost>,
patpro ~ Patrick Proniewski <patpro@boleskine.patpro.net> wrote:
In article <j3ngn7-leu1.ln1@deuxvis.fr>, DeVice <dev.null@deuxvis.fr>
wrote:
> Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace
> si tu préfères, dans les ports) te donnerait plus de précisions sur ce
> qui bloque réellement ?
Bon alors voilà, avec un petit truss rapide :
# truss super-smack update-select.smack 2 10000 2>&1| grep -C2 ERR#25
munmap(0x80107d000,1585152) = 0 (0x0)
open("update-select.smack",O_RDONLY,0666) = 2 (0x2)
ioctl(2,TIOCGETA,0xffffdef0) ERR#25 'Inappropriate ioctl for
device'
fstat(2,{ mode=-rw-r--r-- ,inode0671,size527,blksize384 }) = 0
(0x0)
read(2,"// this is will be used in the t"...,16384) = 3527 (0xdc7)
--
stat("/etc/nsswitch.conf",{ mode=-rw-r--r--
,inodeX8848,size27,blksize384 }) = 0 (0x0)
open("/etc/nsswitch.conf",O_RDONLY,0666) = 3 (0x3)
ioctl(3,TIOCGETA,0xffffda00) ERR#25 'Inappropriate ioctl for
device'
fstat(3,{ mode=-rw-r--r-- ,inodeX8848,size27,blksize384 }) = 0
(0x0)
read(3,"#n# nsswitch.conf(5) - name ser"...,16384) = 327 (0x147)
--
access("/usr/lib/nss_dns.so.1",0) ERR#2 'No such file or directory'
sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0)
ioctl(3,TIOCGETA,0xffffda10) ERR#25 'Inappropriate ioctl for
device'
close(3) = 0 (0x0)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE
RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|S
IGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
--
close(3) = 0 (0x0)
fork() = 21821 (0x553d)
ioctl(2,TIOCGETA,0xffffdf00) ERR#25 'Inappropriate ioctl for
device'
wait4(0x553d,0x0,0x0,0x0,0x4,0x1) = 21821 (0x553d)
sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE
RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|S
IGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
Je dois bien avouer, ça m'aide pas plus. J'ai cherché un peu autour de
TIOCGETA et ioctl, mais sans trouver quelque chose qui me parle vraiment.
des idées ?
patpro
--
A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
> Avant de tâtonner sur les variables, peut-être qu'un ktrace (ou strace > si tu préfères, dans les ports) te donnerait plus de précisions sur ce > qui bloque réellement ?
Bon alors voilà, avec un petit truss rapide :
# truss super-smack update-select.smack 2 10000 2>&1| grep -C2 ERR#25 munmap(0x80107d000,1585152) = 0 (0x0) open("update-select.smack",O_RDONLY,0666) = 2 (0x2) ioctl(2,TIOCGETA,0xffffdef0) ERR#25 'Inappropriate ioctl for device' fstat(2,{ mode=-rw-r--r-- ,inode0671,size527,blksize384 }) = 0 (0x0) read(2,"// this is will be used in the t"...,16384) = 3527 (0xdc7) -- stat("/etc/nsswitch.conf",{ mode=-rw-r--r-- ,inodeX8848,size27,blksize384 }) = 0 (0x0) open("/etc/nsswitch.conf",O_RDONLY,0666) = 3 (0x3) ioctl(3,TIOCGETA,0xffffda00) ERR#25 'Inappropriate ioctl for device' fstat(3,{ mode=-rw-r--r-- ,inodeX8848,size27,blksize384 }) = 0 (0x0) read(3,"#n# nsswitch.conf(5) - name ser"...,16384) = 327 (0x147) -- access("/usr/lib/nss_dns.so.1",0) ERR#2 'No such file or directory' sigprocmask(SIG_SETMASK,0x0,0x0) = 0 (0x0) ioctl(3,TIOCGETA,0xffffda10) ERR#25 'Inappropriate ioctl for device' close(3) = 0 (0x0) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|S IGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0) -- close(3) = 0 (0x0) fork() = 21821 (0x553d) ioctl(2,TIOCGETA,0xffffdf00) ERR#25 'Inappropriate ioctl for device' wait4(0x553d,0x0,0x0,0x0,0x4,0x1) = 21821 (0x553d) sigprocmask(SIG_BLOCK,SIGHUP|SIGINT|SIGQUIT|SIGKILL|SIGPIPE|SIGALRM|SIGTE RM|SIGURG|SIGSTOP|SIGTSTP|SIGCONT|SIGCHLD|SIGTTIN|SIGTTOU|SIGIO|SIGXCPU|S IGXFSZ|SIGVTALRM|SIGPROF|SIGWINCH|SIGINFO|SIGUSR1|SIGUSR2,0x0) = 0 (0x0)
Je dois bien avouer, ça m'aide pas plus. J'ai cherché un peu autour de TIOCGETA et ioctl, mais sans trouver quelque chose qui me parle vraiment.
des idées ?
patpro
-- A vendre ! http://www.patpro.net/blog/index.php/2008/01/12/133
Rodrigo OSORIO (ros)
Bonjour,
Je suis en train de jouer sur une sparc64 avec un port qui à des dépendances avec apache20, mais apache20 retourne un message d'erreur lors de la compilation :
ssl_engine_init.c: In function 'ssl_init_ctx_verify': ssl_engine_init.c:534: error: 'STACK' undeclared (first use in this function)
Après un peu de recherche l'ajout dans le fichier ./work/httpd-2.0.63/modules/ssl/mod_ssl.h de la ligne suivante corrige le problème : typedef struct stack_st STACK;
Pour info : FreeBSD spock 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 06:53:42 UTC 2010 :/usr/obj/usr/src/sys/GENERIC sparc64
Bonjour,
Je suis en train de jouer sur une
sparc64 avec un port qui à des
dépendances avec apache20, mais
apache20 retourne un message d'erreur
lors de la compilation :
ssl_engine_init.c: In function
'ssl_init_ctx_verify':
ssl_engine_init.c:534: error: 'STACK'
undeclared (first use in this function)
Après un peu de recherche l'ajout dans
le fichier
./work/httpd-2.0.63/modules/ssl/mod_ssl.h
de la ligne suivante corrige le problème :
typedef struct stack_st STACK;
Pour info :
FreeBSD spock 8.1-RELEASE FreeBSD
8.1-RELEASE #0: Mon Jul 19 06:53:42 UTC
2010
root@araz.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC
sparc64
Je suis en train de jouer sur une sparc64 avec un port qui à des dépendances avec apache20, mais apache20 retourne un message d'erreur lors de la compilation :
ssl_engine_init.c: In function 'ssl_init_ctx_verify': ssl_engine_init.c:534: error: 'STACK' undeclared (first use in this function)
Après un peu de recherche l'ajout dans le fichier ./work/httpd-2.0.63/modules/ssl/mod_ssl.h de la ligne suivante corrige le problème : typedef struct stack_st STACK;
Pour info : FreeBSD spock 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 06:53:42 UTC 2010 :/usr/obj/usr/src/sys/GENERIC sparc64
talon
patpro ~ patrick proniewski wrote:
In article <4ca506e7$0$27686$, Michel Talon wrote:
> patpro ~ patrick proniewski wrote: > > > > > > super-smack: Error creating semaphore errno = 28, error is No space left > > on device
Merci pour la commande, je n'avais pas trop d'id?e pour v?rifier le message d'erreur. N?anmoins, on dirait que ce n'est pas ?a...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel s 65537 1937850441 --rw-rw-rw- root wheel s 65538 1937850482 --rw-rw-rw- root wheel s 65539 1937850523 --rw-rw-rw- root wheel s 65540 1937850564 --rw-rw-rw- root wheel s 65541 1937850688 --rw-rw-rw- root wheel s 65542 1937850732 --rw-rw-rw- root wheel s 65543 1937850776 --rw-rw-rw- root wheel s 65544 1937850820 --rw-rw-rw- root wheel s 65545 1937850947 --rw-rw-rw- root wheel
Là tu as 10 sémaphores, et j'ai vérifié que par défaut, le nombre 10 est l'une des limites sur les sémaphores. kern.ipc.semmni: 10 Je pense que tu dois augmenter radicalement ces limites pour faire tourner ton script. Voir par exemple ce que dit: http://docs.postgresqlfr.org/8.1/kernel-resources.html Le reste du message n'a visiblement aucun sens.
--
Michel TALON
patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
In article <4ca506e7$0$27686$426a34cc@news.free.fr>,
Michel Talon <talon@lpthe.jussieu.fr> wrote:
> patpro ~ patrick proniewski wrote:
>
>
> >
> > super-smack: Error creating semaphore errno = 28, error is No space left
> > on device
Merci pour la commande, je n'avais pas trop d'id?e pour v?rifier le
message d'erreur. N?anmoins, on dirait que ce n'est pas ?a...
# ipcs -s
Semaphores:
T ID KEY MODE OWNER GROUP
s 65536 1937850369 --rw-rw-rw- root wheel
s 65537 1937850441 --rw-rw-rw- root wheel
s 65538 1937850482 --rw-rw-rw- root wheel
s 65539 1937850523 --rw-rw-rw- root wheel
s 65540 1937850564 --rw-rw-rw- root wheel
s 65541 1937850688 --rw-rw-rw- root wheel
s 65542 1937850732 --rw-rw-rw- root wheel
s 65543 1937850776 --rw-rw-rw- root wheel
s 65544 1937850820 --rw-rw-rw- root wheel
s 65545 1937850947 --rw-rw-rw- root wheel
Là tu as 10 sémaphores, et j'ai vérifié que par défaut, le nombre
10 est l'une des limites sur les sémaphores.
kern.ipc.semmni: 10
Je pense que tu dois augmenter radicalement ces limites pour faire
tourner ton script. Voir par exemple ce que dit:
http://docs.postgresqlfr.org/8.1/kernel-resources.html
Le reste du message n'a visiblement aucun sens.
In article <4ca506e7$0$27686$, Michel Talon wrote:
> patpro ~ patrick proniewski wrote: > > > > > > super-smack: Error creating semaphore errno = 28, error is No space left > > on device
Merci pour la commande, je n'avais pas trop d'id?e pour v?rifier le message d'erreur. N?anmoins, on dirait que ce n'est pas ?a...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel s 65537 1937850441 --rw-rw-rw- root wheel s 65538 1937850482 --rw-rw-rw- root wheel s 65539 1937850523 --rw-rw-rw- root wheel s 65540 1937850564 --rw-rw-rw- root wheel s 65541 1937850688 --rw-rw-rw- root wheel s 65542 1937850732 --rw-rw-rw- root wheel s 65543 1937850776 --rw-rw-rw- root wheel s 65544 1937850820 --rw-rw-rw- root wheel s 65545 1937850947 --rw-rw-rw- root wheel
Là tu as 10 sémaphores, et j'ai vérifié que par défaut, le nombre 10 est l'une des limites sur les sémaphores. kern.ipc.semmni: 10 Je pense que tu dois augmenter radicalement ces limites pour faire tourner ton script. Voir par exemple ce que dit: http://docs.postgresqlfr.org/8.1/kernel-resources.html Le reste du message n'a visiblement aucun sens.
bon, ça se corse, parce que ces erreurs sont aussi présentes quand super-smack fonctionne correctement. Je ne sais plus ou chercher :/
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
Philippe Michel
On 2010-10-01, patpro ~ patrick proniewski wrote:
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel [et 9 autres semaphore IDs]
J'aurais plutôt l'impresssion que c'est ça, justement.
Par défaut, on a droit a 10 semaphore identifiers (cf. ipcs -S ou sysctl -a | grep ipc.sem). Tu es au taquet.
Il faudrait voir la doc de mysql et/ou ce que fait exactement le benchmark, (combien de connexions simultanées ?) mais en général il faut augmenter sensiblement certains de ces paramètres IPC sur les serveurs de bases de données.
On 2010-10-01, patpro ~ patrick proniewski <patpro@boleskine.patpro.net> wrote:
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le
message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s
Semaphores:
T ID KEY MODE OWNER GROUP
s 65536 1937850369 --rw-rw-rw- root wheel
[et 9 autres semaphore IDs]
J'aurais plutôt l'impresssion que c'est ça, justement.
Par défaut, on a droit a 10 semaphore identifiers (cf. ipcs -S ou sysctl
-a | grep ipc.sem). Tu es au taquet.
Il faudrait voir la doc de mysql et/ou ce que fait exactement le
benchmark, (combien de connexions simultanées ?) mais en général il faut
augmenter sensiblement certains de ces paramètres IPC sur les serveurs de
bases de données.
Merci pour la commande, je n'avais pas trop d'idée pour vérifier le message d'erreur. Néanmoins, on dirait que ce n'est pas ça...
# ipcs -s Semaphores: T ID KEY MODE OWNER GROUP s 65536 1937850369 --rw-rw-rw- root wheel [et 9 autres semaphore IDs]
J'aurais plutôt l'impresssion que c'est ça, justement.
Par défaut, on a droit a 10 semaphore identifiers (cf. ipcs -S ou sysctl -a | grep ipc.sem). Tu es au taquet.
Il faudrait voir la doc de mysql et/ou ce que fait exactement le benchmark, (combien de connexions simultanées ?) mais en général il faut augmenter sensiblement certains de ces paramètres IPC sur les serveurs de bases de données.
patpro ~ patrick proniewski
In article <i87or9$37e$, Philippe Michel wrote:
On 2010-10-01, patpro ~ patrick proniewski wrote:
> Merci pour la commande, je n'avais pas trop d'idÈe pour vÈrifier le > message d'erreur. NÈanmoins, on dirait que ce n'est pas Áa... > > # ipcs -s > Semaphores: > T ID KEY MODE OWNER GROUP > s 65536 1937850369 --rw-rw-rw- root wheel > [et 9 autres semaphore IDs]
J'aurais plutÙt l'impresssion que c'est Áa, justement.
Par dÈfaut, on a droit a 10 semaphore identifiers (cf. ipcs -S ou sysctl -a | grep ipc.sem). Tu es au taquet.
pfiou, 10, ok. Je n'avais pas idée que la limite par défaut puisse être aussi basse.
Il faudrait voir la doc de mysql et/ou ce que fait exactement le benchmark, (combien de connexions simultanÈes ?) mais en gÈnÈral il faut augmenter sensiblement certains de ces paramËtres IPC sur les serveurs de bases de donnÈes.
le bench est essentiellement CPU-bound, il balance les requêtes aussi vite que possible (select, et select/update). Je le lance en boucle du genre :
for i in {1..80}; do super-smack fichier-de-test $i 10000 done
où $i est le nombre de clients concurrents qui sont créés par super-smack et 10000 le nombre de requêtes du bench.
Je note ta recommandation pour les param. IPC, néanmoins le serveur sera dans la pratique bien moins chargé que ce que je lui fait subir maintenant, donc je pense que pour la prod ce sera inutile.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
In article <i87or9$37e$1@news.eternal-september.org>,
Philippe Michel <philippe.michel7@sfr.fr.invalid> wrote:
On 2010-10-01, patpro ~ patrick proniewski <patpro@boleskine.patpro.net>
wrote:
> Merci pour la commande, je n'avais pas trop d'idÈe pour vÈrifier le
> message d'erreur. NÈanmoins, on dirait que ce n'est pas Áa...
>
> # ipcs -s
> Semaphores:
> T ID KEY MODE OWNER GROUP
> s 65536 1937850369 --rw-rw-rw- root wheel
> [et 9 autres semaphore IDs]
J'aurais plutÙt l'impresssion que c'est Áa, justement.
Par dÈfaut, on a droit a 10 semaphore identifiers (cf. ipcs -S ou sysctl
-a | grep ipc.sem). Tu es au taquet.
pfiou, 10, ok. Je n'avais pas idée que la limite par défaut puisse être
aussi basse.
Il faudrait voir la doc de mysql et/ou ce que fait exactement le
benchmark, (combien de connexions simultanÈes ?) mais en gÈnÈral il faut
augmenter sensiblement certains de ces paramËtres IPC sur les serveurs de
bases de donnÈes.
le bench est essentiellement CPU-bound, il balance les requêtes aussi
vite que possible (select, et select/update).
Je le lance en boucle du genre :
for i in {1..80}; do
super-smack fichier-de-test $i 10000
done
où $i est le nombre de clients concurrents qui sont créés par
super-smack et 10000 le nombre de requêtes du bench.
Je note ta recommandation pour les param. IPC, néanmoins le serveur sera
dans la pratique bien moins chargé que ce que je lui fait subir
maintenant, donc je pense que pour la prod ce sera inutile.
patpro
--
A vendre : KVM IP 16 ports APC
http://patpro.net/blog/index.php/2008/01/12/133
> Merci pour la commande, je n'avais pas trop d'idÈe pour vÈrifier le > message d'erreur. NÈanmoins, on dirait que ce n'est pas Áa... > > # ipcs -s > Semaphores: > T ID KEY MODE OWNER GROUP > s 65536 1937850369 --rw-rw-rw- root wheel > [et 9 autres semaphore IDs]
J'aurais plutÙt l'impresssion que c'est Áa, justement.
Par dÈfaut, on a droit a 10 semaphore identifiers (cf. ipcs -S ou sysctl -a | grep ipc.sem). Tu es au taquet.
pfiou, 10, ok. Je n'avais pas idée que la limite par défaut puisse être aussi basse.
Il faudrait voir la doc de mysql et/ou ce que fait exactement le benchmark, (combien de connexions simultanÈes ?) mais en gÈnÈral il faut augmenter sensiblement certains de ces paramËtres IPC sur les serveurs de bases de donnÈes.
le bench est essentiellement CPU-bound, il balance les requêtes aussi vite que possible (select, et select/update). Je le lance en boucle du genre :
for i in {1..80}; do super-smack fichier-de-test $i 10000 done
où $i est le nombre de clients concurrents qui sont créés par super-smack et 10000 le nombre de requêtes du bench.
Je note ta recommandation pour les param. IPC, néanmoins le serveur sera dans la pratique bien moins chargé que ce que je lui fait subir maintenant, donc je pense que pour la prod ce sera inutile.
patpro
-- A vendre : KVM IP 16 ports APC http://patpro.net/blog/index.php/2008/01/12/133
