Bonjour,
en observant de plus près les logs de mon serveur ..  
Lorsque mon script de sauvegarde de ma db (php) tourne, ainsi que certains traitements lourds d'entretien .. ce dernier monopolise tout le processeur, parfois sur 40, voir 50 sec ..
 
Le fait accomplit, lorsque le serveur reçoit d'autres connexions (lorsque ce script tourne),  
de nombreuses lignes de logs de visiteurs normaux aboutissent à une erreur 500
( timeout > 30 sec d'éxecution php ), en cascade ..
 
Y'à t-il un moyen de limiter l'usage du processeur par processus php, genre 50%,  
ou de déclarer cela via un "ini_set", afin de limiter ces congestions soudaines ?
 
Merci  

Question peut-être bête, mais pourquoi ne pas laisser le proc à 100% ? tu as d'autres services sur ton serveur ?

pour permettre aux visiteurs sur d'autres page d'accèder aux sites au lieu d'être bloqués ..

Sous Windows tu peux toujours utiliser cet utilitaire http://bitsum.com/prolasso.php  
 
Sous Linux il y a ça: http://www.howtoforge.com/how-to-l [...] ian-ubuntu

1) Assure-toi que tu n'es pas en mode php-cgi (ce mode est très consommateur de ressources)
 
2) Fait de temps à autre des sleep ou des usleep (Voir la doc PHP)
 
3) Choppe la consommation CPU si t'es sous Unix :
 

<?php
 
function getCpuUsage() {
  $out      = shell_exec('ps aux|awk \'NR > 0 { s +=$3 }; END {print s}\'');
  $cpuUsage = strtr(trim($out), array("\n"=>'', "\r"=>''));
  return $cpuUsage;
}
 
while (getCpuUsage() > 50) {
  sleep(1);
}
 
?>

pas bête, mais si par exemple, le script appelle du shell, qui met 50 sec à s'executer ..  
le process ne pourra pas sleeper tant que le retour du shell n'est pas complet ??

Je te rassure, un ps aux, c'est très rapide. Mais tu peux aussi l’exécuter en background avec un &, si tu veux

Mhhh ce serait sympa que tu m'indiques la démarche du "&" merci bcp pour ta réponse

A la fin de la ligne de commande tu ajoutes :
 
 > /dev/null 2>/dev/null &
 
Ce qui a pour effer de lancer la commande en background, en redirigeant les sorties 1 (standard) et 2 (erreur) vers /dev/null (poubelle).
 
C'est à mon avis inutile dans ton cas, pour récupérer un ps aux !
Autant faire le sleep() tout seul dans ce cas  
 
Par contre, pour lancer un programme en arrière plan et/ou faire du multithreading, c'est d'la bombe atomique [XP perso inside]

D'un côté on ne fait pas de traitement de maintenance sur une base de prod. n'importe quand.
Programme la nuit le via crontab ou autre et puis voilà...
 
D'autant que vu qu'il n'y a aucune raison qu'une instance PHP ralentisse drastiquement une autre instance PHP, je suppose que le timeout est du à la BDD qui doit être +/- à la ramasse et/ou lockée à cause des traitements de maintenance.

c'est exact je l'ai programmé pour 3h du mat, à usage minimum.
Le lockage se fait car attente de résultats d'une commande de shell (30sec)
et lockage bdd sur 15 sec environ pour le backup

Aaaaahhh, d'accord !  
 
Si c'est réellement la commande shell qui bloque (et non la BDD), alors effectivement lancer cette commande en arrière plan pourra t'aider !
 

<?php
 
// Background process :
// We do not wait the command execution to return
shell_exec('ma_commande > /dev/null 2>/dev/null &');
 
?>