processeur + requete SQL

processeur + requete SQL - SQL/NoSQL - Programmation

Marsh Posté le 04-07-2017 à 10:51:16    

Bonjour, désolé je sais pas si je suis dans la bonne section,
 
juste une question pour savoir ce qui est solicité dans les requetes SQL (insertion et update)
 
ma config localhost
Core i7-6700K
GPU GTX-1070
SSD 520mo/s dédié aux base de donnée
 
Ca va assez vite mais je dois régulièrement faire des updates je me demande quoi overcloker pour gagner en rapidité  
 
Pour le proc, j'ai OC à 4500 avec un ratio de 42x
 
Dans le gestionnaire des taches, apache est utilisé a 0,8% et mysql a 4% j'aimerais que ca monte au moins a 85% lorsque je fais des gros dump
 
J'ai boosté le GPU mais j'ai pas l'impression qu'il est utlisé (dans le graph)
Comment pousser à fond l'utilisation d'apache ?
 
Merci


Message édité par monpseudo78 le 04-07-2017 à 10:54:07
Reply

Marsh Posté le 04-07-2017 à 10:51:16   

Reply

Marsh Posté le 04-07-2017 à 11:21:10    

Je crois ca vient de ma version apache qui est 32Bits
je m'étais habitué à une version easyphp qui date de très loin et d'un ancien ordi, faut que je passe tout en 64 bits ?
 
Je comprends plus rien aux versions easyphp (ils appel ça devserver)
c'est quoi tout ces truc ?
 
j'ai juste besoin d'un apache et mysql 64 bits,  
(pas besoin de python, ni perl et ruby)


Message édité par monpseudo78 le 04-07-2017 à 11:22:03
Reply

Marsh Posté le 04-07-2017 à 14:02:33    

j'ai testé avec un easyphp v14 qui est toujours en 32bits aucun changement toujours 3-4% d'utilisation d'apache
 
J'ai tester wamp qui lui est un vrai 64 bits (selon leur site) un vrai package des dernières versions apache & mysql et c'est pareil ca ne change rien. 3-4% d'utilisation de mysql
 
Est-ce que je dois aller vers un meilleur SSD en écriture ? du genre cela http://www.ldlc.com/fiche/PB00219275.html
Il écrit à 1500mo/s
 
Croyez vous qu'apache & mysql soit bridé avec une faible utilisation du processeur ?
Je vais rester sur la très ancienne version easyphp, ca m'a rien changé


Message édité par monpseudo78 le 04-07-2017 à 14:03:09
Reply

Marsh Posté le 04-07-2017 à 14:34:33    

Je ne sais pas exactement ce que fait ton apli mais si c'est du traitement en BDD, ca m'étonnerait que le goulot d'étranglement soit au niveau d'apache, je pencherais plutôt pour Mysql, tu as essayé de bidouiller le fichier de conf pour optimiser ça ?
https://www.google.fr/search?q=mysql+optimisation
Il existe un script perl (mysqltuner.pl) qui permet d'analyser le process Mysql et propose des amélioration...
 
Sinon voir au niveau de tes tables si tout est bon : présence des index, moteur de stockage adapté, etc...
Quel est la taille total de ta database, tu aurais ptet de bon résultat en la mettant dans la RAM.


---------------
D3
Reply

Marsh Posté le 04-07-2017 à 15:01:21    

Merci, oui ce serait plutot Mysql qui devrait bosser, apache est juste le lancement du serveur
 
Tu m'a donner une bonne idée de mettre mysql en ram, je sais pas comment faire mais je vais me renseigner
 
au sujet des tables c'est prestashop deja optimisé où tout y est,
la base est vide, je fais des test d'insert et d'importation voir comment le localhost réagit
 
Le SSD montre des écritures de 3mo/s durant 'l'import et les requètes, alors qu'il devrait bosser à 530mo/s.
Ca viendrait aussi peut être de là ?


Message édité par monpseudo78 le 04-07-2017 à 15:01:36
Reply

Marsh Posté le 04-07-2017 à 15:20:22    

Lors d'imports dans MySQL, je te recommande de supprimer tout ce qui est index, vérif de l'intégrité des clés étrangères... Une fois l'import terminé, tu remets tout en place. En effet, à chaque insert, Mysql va recalculer les index et faire la vérif d'intégrité/contrainte des clés étrangères. Du coup, ça ralentit beaucoup :o
 
Après, c'est clair qu'il faut optimiser Mysql et privilégier l'utilisation en RAM. De même, apparemment, MariaDB (fork de MySql) avec son moteur Aria serait plus performant que Mysql.
 
+1 pour wamp par rapport à easyphp qui a mal vieilli.
 
Edit : j'ai pu constater qu'un AMP sous Windows était bien plus lent et avait beaucoup plus de mal à gérer les accès concurrents/multi-threads que sous un Linux sur du matériel identique.


Message édité par rufo le 04-07-2017 à 15:22:04

---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 04-07-2017 à 15:39:28    

j'ai trouvé des topic pour mettre mysql en ram mais uniquement sur linux et debian mais pas sur win10.
 
La base est vraiment vide, je viens de faire un benchmark du ssd il montre bien les 530mo/s pareil pour des copier coller de gros fichier on est dans ces mesures.  
 
Dés que ca bosse en base de donnée ca chute a 3-4mo/s  
je sais que sur les petits fichiers qui pèse pas lourd ca ralenti le débit, mais on est très loin d'un 200 ou meme 60mo/s
 
Je crois pas que ca vienne du SSD, Le tout est déjà rapide en faite, il rempli environ 100 lignes par seconde sur 4 table à la fois, donc c'est déjà bien, mais je trouve suspect, que l'utilisation soit d'à peine 5% (du proc) pour mysql et que le SSD bosse à 3mo/s
 
Oui easyphp est devenu le bordel sur les nouvelles version, je comprends rien à leur truc dev.  
Wamp meme si les repères changent on s'y fait assez vite  
 
quelques soit la version utilisé : wamp ou easyphp 2,10 ou meme la 14 j'ai toujours 100 lignes à la secondes, et les meme mesures au niveau du proc et cela pareil en overclock a 4600 ratio x42
rien ne bouge je comprends pas
 
Aussi quand l'importation franchit le cap des 50.000 lignes sur les 4 table , ce n'est plus 100 ligne par seconde mais plutot 50-75, ce qui surement normal, mais je comprends pas, pourquoi dés le début il ne fait pas 1000 ou 1500 lignes par secondes ou un peu plus de 100


Message édité par monpseudo78 le 04-07-2017 à 15:40:07
Reply

Marsh Posté le 04-07-2017 à 16:08:10    

j'ai supprimé 2 tables qui me serve à rien dans l'import de ce que je veux faire et je passe à 350-400 lignes seconde j'aurais bien supprimé la 3eme qui me sert à rien aussi mais elle est neccessaire pour remplir la 4eme.
 
Donc ca l'air d'un problème "logique" sauf que je comprends toujours pas pourquoi le proc et le SSD semble "bridé" et que l'overclock ne joue pas dessus

Reply

Marsh Posté le 04-07-2017 à 17:47:21    

T'as désactivé les index et autres contrôles de contraintes comme je l'ai indiqué ?


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 04-07-2017 à 20:17:35    

non comment je fais ca ?

Reply

Marsh Posté le 04-07-2017 à 20:17:35   

Reply

Marsh Posté le 04-07-2017 à 23:09:50    

Les index, tu les supprimes (alter table via phpmyadmin, mais tu sauvegardes avant quels index étaient présents dans chacune des tables). Les contraintes, tu les désactives (cherche dans la doc de Mysql); à faire que si tu es sur un moteur innodb.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 05-07-2017 à 04:08:50    

d'accord merci j'ai trouvé ca  
 
DROP INDEX matable;
 
C'est de ca qu'on parle ?
en fait les tables sont vides, y'a rien a supprimé, je fais des import sur une base vide et même le ibdata est vide à part les créations des tables
 
ca m'envoi 0 enregistrement


Message édité par monpseudo78 le 05-07-2017 à 04:09:14
Reply

Marsh Posté le 05-07-2017 à 09:33:29    

Oui, c'est bien drop index matable. Même si la table est vide, quand tu vas faire les insert, l'index va être recalculé à chaque fois pour équilibrer l'arbre. Donc, ça ralentit.


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 05-07-2017 à 12:48:32    

je l'ai fais ca change rien, toujours les même mesures (5-6 % de proc)
 
j'ai plus que 8 tables et uniquement 2 qui se remplisse donc ca va assez vite, environ 300 ligne seconde.  
 
je peux voir en direct car les table se remplisse tandis que durant les update je vois rien car il est fait sous ligne de commande et j'attends environ 5-10 minutes que ca se termine.
 
ton proc aussi est a 5% ?  
je me demande pourquoi tous les serveur bosse sur du Xeon, il serait mieux optimisé pour ce genre de truc ?

Reply

Marsh Posté le 05-07-2017 à 13:58:38    

Comme indiqué, pour du multi-thread/multi-process, vaut mieux bosser sur du Linux :o


---------------
Astres, outil de help-desk GPL : http://sourceforge.net/projects/astres, ICARE, gestion de conf : http://sourceforge.net/projects/icare, Outil Planeta Calandreta : https://framalibre.org/content/planeta-calandreta
Reply

Marsh Posté le 05-07-2017 à 18:11:31    

j'ai des VPS en linux, j'y comprends rien, je sais juste installer les services, pour que ca fonctionne, avec les commandes courantes.
 
J'évite les gros update directement sur les VPS car les processeurs sont très faible je fais tout en localhost et apres je transfert chez eux
 
Un linux à la maison oui j'aimerais essayer, au moins pour mieux comprendre ma grappe de VPS et voir comment je pourrais encore mieux l'optimiser chez l'hebergeur.
 
Merci pour le temps que t'as pris avec moi c'est sympa ;)


Message édité par monpseudo78 le 05-07-2017 à 18:12:25
Reply

Sujets relatifs:

Leave a Replay

Make sure you enter the(*)required information where indicate.HTML code is not allowed