Il galèrait sec en 2018. Même si j'ai de la famille d'origine polonaise, je pratique pas
c'est du google trad brut de coffrage.
Si vous voulez, les sources sont toujours accessibles en ligne.
Son dernier post de son blog perso:
9 JANVIER 2018 PAR GOOFYX
Optimisation des analyseurs
Sur 8 scripts qui pouvaient tuer l'ordinateur traitant les données avec plus de résultats, il n'y avait que 4 scripts universels avec des paramètres. La deuxième étape consistait à exécuter les scripts un par un au lieu de tous en même temps.
Cependant, l'étape la plus importante que j'avais planifiée depuis plus de 2 ans (et que je ne voulais pas faire) était de créer une table temporaire avec des informations sur les utilisateurs et les fichiers de résultats qu'ils renvoyaient dans GG @ h NCI avant chaque exécution des analyseurs. L'introduction de cette solution a été un véritable jalon car le temps d'une requête à la base de données est passé de 5 minutes à 5 secondes <- littéralement. Vous pouvez maintenant imaginer que chaque analyseur effectue plusieurs centaines (et parfois plusieurs milliers) de telles requêtes. Maintenant, les analyseurs traitent en 5 minutes ce qui était auparavant fait en 2 jours. Des progrès sont visibles ... probablement 😉
Sur le forum de son équipe, sa dernière question:
«Le: 05 avril 2018, 22:34» peut-être que quelqu'un me conseillera quelque chose.
La situation dans la version chronologique ressemble à ceci:
1. Le processeur GG @ h démarre lors de l'installation propre de debian, compilation du serveur boinc propre en tant que VPS <- qui s'est déjà échappé avec 20 hôtes
2. J'ai fait une sauvegarde vps en utilisant CloneZilla et j'ai restauré cette copie sur du matériel physique <- un tour de hp proboook lite ou quelque chose comme ça. Et c'est même allé avec 250 hôtes
3.En lapku, j'ai remplacé le disque par hdd 5400 tr / s en ssd (sata probablement 1) et de la même manière que ci-dessus c'est-à-dire une copie de cloneZilla et une restauration vers ssd <- et il est même allé à 600-700 hôtes ... et il s'est échappé avec 1k hôte
4.J'ai acheté du nouvel équipement (mobo, cpu, psu, ram, etc.), j'y ai connecté un SSD avec un système de patte et de légers problèmes ont commencé <- au début, ils n'étaient pas graves ... 30 minutes mais excrété chez 3k hôtes
5.J'ai appris que les INods (partition ext4) sont essentiellement vides sur le disque en raison de dizaines de millions de petits fichiers
6. J'ai acheté un second ssd, créé une partition XFS, je l'ai déplacé vers fstab et mappé le répertoire / home <dans fstab - inode est ok sur les deux lecteurs.
Le problème est que la base de données meurt simplement avec une charge plus élevée sans donner aucune information dans les journaux ... <- il n'y a rien sur les erreurs dans les journaux système ... les journaux se interrompent simplement lorsque le disque cesse de répondre.
cependant, ce qui m'a rendu curieux, c'est que non seulement la base de données est en train de mourir, mais fondamentalement tout le serveur ...
en regardant les graphiques de munin, il s'avère que lorsque le lecteur ssd avec le système et la base de données commence à être plus chargé, il meurt. Après avoir redémarré l'ordinateur pendant 5 à 10 minutes, j'ai des messages indiquant que le système a supprimé l'inode orphelin et qu'il a réparé certains iniode / secteur <- les tests intelligents ne montrent rien.
Fait intéressant, j'ai essayé de désactiver apache2, mysql et le projet et de faire des tests de performance avec certains scripts et dd ... tous ont passé positivement, même ceux qui fonctionnent pendant 10 à 15 minutes.
1. La seule chose qui me vient à l'esprit est le fait que le disque a été installé sur un autre ordinateur et que je l'ai changé pour un nouvel équipement.
2.un tel comportement est également lié au fait que quelque chose ne va pas avec le disque ou la partition, le système détecte une erreur de disque / partition et le connecte en mode lecture seule
un tel changement de matériel "hamska" peut-il provoquer un tel résultat?
Le dernier signe de vie pour son équipe:
GoofyxGrid NCI est de retour.
tito 04-07-2019 Projets BOINC polonais
Projet GoofyxGrid @ home NCI fonctionne à nouveau après une longue période (malheureusement - aucune information de l'administrateur).
En ce moment, le site de Boinc@Poland a aussi quelques soucis de bases de données, essayez le wiki par ex.
Pour ma part, en redémarrant mon activité boinc, j'ai récupéré 4 goofyx nci prêtes à valider le 30/08/2020