Plantages récurrents, solution(s) ?

le problème est simple
- j'ai payé pour 11mois et 20 jours
- le remboursement, dans les CGU est impossible :
https://wiki.gandi.net/fr/iaas/references/billing/...
Donc si on part, on perd 320€, plus l'investissent des 140€ qui nous restent pour le nouveau serveur.
Voilà.

Ha, ben voilà...
Merci Joebar pour cette info capitale.

Je suis un peu perdu. La solution 2 consistait à augmenter les ressources (j'avais traduit augmenter la mémoire ou la puissance du serveur), et ça n'était qu'une question de finance. J'avais donc proposé une aide financière. Mais la solution 3 qui est surement la meilleure à terme coûte encore plus chère, et demande beaucoup d'investissement technique.

Si j'ai bien tout compris, on doit pouvoir rester sur le même serveur/hébergeur jusqu'à la fin du contrat actuel (pour ne pas perdre tout ce qui est payé d'avance), en augmentant la ressource (ma proposition d'apporter de l'argent), puis effectuer le changement d'hébergeur en fin du contratactuel.

C'était le sens de ma proposition. Mais j'ai peut-être compris de travers.

Merde !

Bjr Herpac. Tout d'abord merci pour ton offre. Si le remboursement n'est pas possible alors il faut faire au moins cher cad déterminer la mémoire minimum nécessaire pour ne pas sur équiper la machine. En début de semaine, j'ai modifié les paramètres du serveur en espérant qu'il y aurait un 'mieux' .. malheureusement, ce n'est pas probant. Il y a eu 1 plantage et 1 ou 2 blocages depuis mais bon un Giga c'est peu. Il faudra peut être doubler la capacité mémoire en prélevant sur le 'crédit' disponible, ce qui augmentera naturellement la facture mensuelle et diminuera la durée de l'hébergement. Cela dit, ça ne m'empêche pas de chercher à raboter voir supprimer des tâches 'accessoires' du système pour libérer de la Ram.

J'ai remonté un site 'test' sur une de mes machines afin de bricoler sans déranger le réseau. Avec un peu de chance qui sait ... il y a peut être une solution qui se cache dans ces milliers de lignes de codes..

Bon dimanche !

Alors en doublant, on arrive à combien par mois?

Apparemment c'est 4.49 le giga supplémentaire.

Ok, donc on arrive à 2 giga, rendus possibles par la proposition d'Herpac sur les 11 mois déjà engagés. Ça suffirait en attendant un possible désengagement?

Bien que désengagé, voici quelques éléments pour vous aider à avancer encore (bien que ce soit déjà le cas en seulement 2 pages, chose inhabituelle sur tcb :D ...).

Clairement, la migration n'est plus envisageable actuellement et je pense que, tout comme l'extension des options sur le serveur actuel, la dépense ne règlera pas tout - voire rien. Il faut de l'analyse d'erreur avancée et du règlage affiné (que Pascal ne peut couvrir solo).

La plupart des plantages l'an passé étaient liés à mysql et l'automatisation de sa maintenance a réduit ces incidents. Et ceux qui ont lieu ces derniers temps sont a priori dûs dans 9 cas sur 10 à une saturation mémoire d'apache. J'en ai donc automatisé la maintenance également à un rythme accru.

Je n'en ferais pas davantage, comme signalé je passe la main et ne souhaite pas reprendre de mandat. J'espère que ça tiendra bon le temps que vous trouviez du monde pour prendre le relai et aider Pascal ... bonne année à vous

Bonne année à toi aussi

Les choses se compliquent grandement... De mon point de vue de noob absolu en tous cas.

Je ne connais pas d'autres membres compétents sur la maintenance réseau que ceux déjà impliqués (à un moment ou un autre).

Déjà on pourrait envoyer quelques annonces "officielles" sur le réseau, ainsi que sur twitter et FB.

Dans le même temps que chacun fasse de même dans son cercle d'amis et contacts.

Merci à toi et bonne année itou

0/15 * * * * service apache2 restart

Je n'ai pas osé ... je trouvais ça bourrin.

La cadence me semble un peu élevée,j'ajusterai si nécessaire.


Merci Beatnick.

mail reçu de gandi le 7 Janvier 2016 19:45 :
"Bonjour,
Ceci est un mail automatique pour vous prévenir qu'une de vos sondes vient d'être déclenchée sur votre serveur tcbsrv01.
Les paramètres de cette sonde sont ;
Charge > 90 % pendant 10 minutes"


mail reçu de gandi le 7 Janvier 2016 22:45 :
"Bonjour,
Ceci est un mail automatique de rétablissement pour vous prévenir que la sonde avec les paramètres Charge > 90 % pendant 10 minutes est repassée sous vos critères pour le serveur tcbsrv01."

Si vous voyez à quoi ça correspond , mais pour ceux qui ont les logs :
https://www.gandi.net/admin/hosting/iaas/stats/cha...

Ouaip, reçu idem, mais ni je vois, ni les logs

Les deux lignes qui suivent pourraient expliquer plusieurs soucis rencontrés sur le réseau.

Mais les deux principaux sont celui de la réactivité du réseau ( bug de post, de notification, de chargement longs etc) ainsi que celui des crash mysql.

La première ligne déclare que le programme dispose de 2giga de mémoire et la seconde fait qu'un programme reste actif éternellement tant qu'il n'a pas accompli toutes ces actions (pas de programme) .. par exemple : interrogation de la base de donnée, d'un site externe, d'une ressource interne etc, ce qui se traduit par une navigation erratique voire impossible (page blanche au pire).

@ini_set('memory_limit', '2048M');
@set_time_limit(0);

J'ai donc remplacé ça par :

@ini_set('memory_limit', '1024M');
@set_time_limit(60);

1024M = 1Giga = la mémoire disponible sur notre machine
et 60 secondes au max - le programme abandonne son traitement et rend la main au système donc au navigateur.

Ce qui explique qu'au fil du temps, je voyais en permanence un service apache a 99,5% d'usage de CPU occasionnant le déclenchement d'alerte Gandi mais surtout une grosse lenteur !

Autre chose, un programme qui accède à une base de données établie un connexion à celle ci qui se libère lorsque la transaction est terminée. Si le programme plante durant la transaction et qu'il ne ferme pas la connexion alors l'espace mémoire alloué par le serveur mysql n'est pas libéré => crash mysql

Voilà .. je ne crie pas victoire, pas encore mais je pense que ça risque de repousser une lourde opération aux calanques Grecques