NPDS : Gestion de contenu et de communauté

Plus moyen de faire une sauvegarde avec SavemySQL, ce qui suit s'affiche au lieu d'ouvrir la fenêtre de téléchargement :

Warning: mysql_num_fields(): supplied argument is not a valid MySQL result resource in /..../www/admin/savemysql.php on line 50

PKvwo0ЃY‡№tЎu‚”autoroute411a-150304.
... ETCETERA, je vous passe la suite ;-)

Mis à part cela le site semble bien fonctionner, aucune table ne semble vérolée.
Help. Merci par avance.
:-?

[ Message édité par : Patrick : 15-03-2004 20:58 ]

à mon avis, y'as un problème de zip entre ton butineur et le serveur.
Mod GZIP est activé sur ton serveur ?

Je suis hébergé chez ovh et avant ce w-e ça marchait !
Phpinfo me donne: Zip support = enabled

A voir avec OVH pour l'instant

Merci pour ce diagnostic Dev, je fais un mail à OVH. A suivre donc.

J'ai posé la question et j'attends une réponse. Mais je me demande tout de mêm s'il n'y a pas un blème NPDS : le 28/02 je fais une sauvegarde et le zip fait 716Ko.
Le 11/03 une nouvelle sauvegarde me fait un zip de 1.321 Ko ! Le double en moins de 15 jours !?


[ Message édité par : Patrick : 15-03-2004 20:56 ]

entre les deux tu ne serait pas passer en Coyote par zazard ?

Non, ça c'est certain; cela fait assez longtemps que je vogue en dernière version. Entre ces 2 dates j'ai juste installé pour test le module ecarte de Tribal-Dolphin, avec juste un seul record dans une table. Les dolphins, ça peut pas se reproduire à cette vitesse ;-)

Bizarre de chez bizarre...
Si je dézippe ma sauvegarde du 28/02 j'ai un .sql de 2.563 Ko
Si je dézippe ma sauvegarde du 11/03 j'ai un .sql de 9.590 Ko, et mon éditeur n'arrive même pas à le charger !?
Il me semble avoir lu dans le forum que la db de qlq d'autre enflait aussi !?
Ya un truc bizarre là, c'est pas possible de tripler en qlq jours une db qui vit depuis 3 ans !?
:-?

sauf si tu clique dans les forums ... sur marquer tous les post comme lut ....

J'ai posé la question chez OVH et voilà leur réponse:
"Nous n'avons pas modifié la configuration de nos serveurs mutualisés récemment. L'erreur que vous mentionnez indique que le résultat obtenu lors d'une requête MySQL n'est pas valide, ce qui implique que le script essaie d'obtenir quelque chose de la base et que ce quelque chose n'existe plus dans la forme escomptée. Je vous évite à vérifier votre base".
Ce qui est curieux c'est que ce matin vers 8 heures j'ai refais une tentative et que cela a fonctionné; mais à présent cela ne fonctionne de nouveau plus (même message d'erreur).
:|
Je ne suis pas avancé.
:-?

Pour info, ma communication à OVH:
------------------------------------------------------
Dans l'attente de votre réponse, j'ai refais une nouvelle tentative ce matin vers 08:00, et là le script a parfaitement fonctionné.
Vers 11 heures j'ai refais un essai et là cela ne fonctionnait de nouveau plus.
Et maintenant à 11h44 cela fonctionne à nouveau.

Cela ne doit donc pas être du au script, et toutes les tables sont Ok et optimisées.

Je signale que ma dB a considérablement gonflé ces derniers temps.
Le dernier zip chargé à 11h44 fait 1.316 Ko et le sql qu'il contient pèse 9.481 Ko !

N'y a t'il pas un problème de délai de création du zip qui ferait que le serveur interrompe le traitement, par exemple ?
------------------------------------------------------
Ce que j'avance, c'est possible Dev ?

Réponse OVH :
-------------------------
Je ne peux malheureusement pas vous apporter d'autre réponse étant donné que je n'ai pas accès aux scripts de votre hébergement et que je ne connais pas leur fonctionnement. De notre côté, tout semble correct.
--------------------------------------
:| :-? :-o

cela ressemble quand même à un plantage de leur compresseur GZIP (Par défaut sauveMysql l'utilise) donc cela peut dépendre de la charge de leur serveur !

Sans doute, je viens de réessayer à l'instant, et là ça fonctionne.
On va en rester là. Merci Dev.

ils sont souvent tout de même pénibles chez OVH, maintenant il n'est plus possible de faire tourner ce script de sauvegarde, à chaque fois:
Bonjour,

Okillerd a detecté que l'un de vos scripts ne s'exécute
pas normalement: il prend trop de resources machine.
Il s'agit de:
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
2337 22582 43.6 0.0 0 0 ? Z 19:47 0:13 [php <defunct>]


Merci de:
- TOUTE URGENCE arrêter l'utilisation de ce script
et de fixer le problème.
- nous renvoyer cet email en nous confirmant que vous
avez bien fait le nécessaire.

Dans le cas contraire, nous allons intervenir en bloquant
soit le script soit le site entier.

L'explication:
Votre script a été killé car il a pris équivalent de
0:10 minuite de CPU à 100% et il continue
à avoir besoin au minimum 15 % de CPU.

BEN LA C'EST FOUTU!

La db est trop importante et le temps de traitement / charge est devenue trop grande pour un mutualisé Ovh :-(
J'aurais jamais dû faire "marquer tous les forums comme lus", c'est ça qui a fait doubler la dB !

Dev : ya pas moyen de faire une sorte de "marche-arrère" à cela ? Je sais pas moi, du genre repartir avec tous les forums comme "non lu" pour tous ?
Chaque membre régulier n'aurait qu'à "marquer tous les sujets comme lus" pour retrouver la situation normale.
Est-ce possible ?

voui : tu vide la table forum_read tous simplement

Excellent. Il me reste à prendre la décision du oui ou non. Si oui je pourrais prévoir ça juste après une lettre de news par laquelle je conseillerais aux membres réguliers de faire un "marquer comme lu" sur les thèmes du forum qui les intéressent. Ca mettrait du baume.
Merci beaucoup Dev.

Je ressorts cet ancien post pour cette question :
Quelle incidence cela a t'il si on vide la table forum_read, cette table fait chez moi 40 Mo :#