Seuils d'utilisation optimale du processeur

Question

J'ai construit un logiciel que je déploie sur un serveur Windows 2003. Le logiciel fonctionne en permanence comme un service et c'est la seule application sur la boîte Windows d'importance pour moi. Une partie du temps, il récupère des données sur Internet, et une partie du temps, il fait des calculs sur ces données. C'est multithread - j'utilise des pools de threads d'environ 4-20 threads. Je ne vous ennuierai pas avec tous ces détails, mais il suffit de dire que si j'active plus de threads dans le pool, plus de travail simultané se produit, et l'utilisation du CPU augmente. (Tout comme la demande pour d'autres ressources, comme la bande passante, bien que cela ne me concerne pas - j'en ai plein)

Ma question est la suivante: dois-je simplement essayer de maximiser le processeur pour obtenir le meilleur pour mon argent ? Intuitivement, je ne pense pas qu'il soit logique de fonctionner à 100% CPU; même 95% CPU semble élevé, presque comme si je ne donnais pas beaucoup d'espace à l'OS pour faire ce qu'il doit faire. Je ne connais pas la bonne façon d'identifier le meilleur équilibre. Je suppose que je pourrais mesurer et mesurer et probablement trouver que le meilleur débit est atteint à une utilisation moyenne de CPU de 90% ou 91%, etc. mais ...

Je me demande juste s'il y a une bonne règle empirique à propos de ça??? Je ne veux pas supposer que mes tests tiendront compte de toutes sortes de variations de charges de travail. Je préfère jouer un peu en sécurité, mais pas trop en sécurité (ou bien je sous-utilise mon matériel).

Que recommandez-vous? Qu'est-ce qu'une règle d'utilisation intelligente et orientée vers la performance pour une application à plusieurs threads, à charge mixte (une partie des E/S, un peu de CPU) sous Windows?

Answer 1

Eh oui, je vous suggère de 100% est donc débattait ne voudrait pas voir les processus en cours d'exécution comme ça tout le temps. J'ai toujours visé 80% pour obtenir un équilibre entre l'utilisation et la place pour les pointes/processus ad-hoc. Une approche que j'ai utilisée dans le passé est d'augmenter la taille du pool lentement et de mesurer l'impact (à la fois sur le CPU et sur d'autres contraintes telles que IO), vous ne savez jamais, vous pourriez voir que goulot.

Answer 2

Si vous accordez simplement une priorité faible à vos threads, le système d'exploitation fera le reste et effectuera des cycles de fonctionnement. Server 2003 (et la plupart des OS serveurs) sont très bon à ce, pas besoin d'essayer de le gérer vous-même.

Answer 3

En supposant rien d'autre importance, mais le système d'exploitation fonctionne sur la machine:

Et votre charge est constante, vous devriez viser à 100% d'utilisation du processeur, tout le reste est une perte de CPU. Rappelez-vous que le système d'exploitation gère les threads afin qu'il puisse fonctionner, il est difficile d'affamer le système d'exploitation avec un programme bien comporté. Mais si votre charge est variable et que vous vous attendez à des pics que vous devriez prendre en considération, je dirais que 80% de CPU est un bon seuil à utiliser, sauf si vous savez exactement comment cette charge va varier et combien de CPU cela demandera , auquel cas vous pouvez viser le nombre exact.

Answer 4

utilisation du processeur ne devrait pas question dans ce i/o la charge de travail intensive, vous vous souciez de débit, donc essayez d'utiliser un hill climbing approach et essayer essentiellement par programme injection/suppression de threads de travail et de suivre les progrès d'achèvement ...

Si vous ajouter un fil et ça aide, en ajouter un autre. Si vous essayez un thread et que ça fait mal, retirez-le.

Finalement, cela se stabilisera.

S'il s'agit d'une application basée sur .NET, l'escalade a été ajoutée au pool d'unités d'exécution .NET 4.

MISE À JOUR:

escalade colline est une approche basée sur la théorie du contrôle de débit maximiser, vous pouvez l'appeler tâtonnement si vous voulez, mais il est une bonne approche. En général, il n'y a pas de bonne règle à suivre ici car les frais généraux et les latences varient tellement, il n'est pas vraiment possible de généraliser. L'accent devrait être mis sur le débit & achèvement tâche/thread, pas l'utilisation du processeur.Par exemple, il est assez facile d'associer les noyaux assez facilement avec une synchronisation grossière ou fine, mais cela ne fait pas vraiment de différence dans le débit.

En ce qui concerne .NET 4, si vous pouvez recadrer votre problème en tant que Parallel.For ou Parallel.ForEach, le pool de threads ajustera le nombre de threads pour maximiser le débit, donc vous n'avez pas à vous en préoccuper.

-Rick

Answer 5

J'ai également utilisé 80% comme règle générale pour l'utilisation de la CPU cible. Comme d'autres l'ont mentionné, cela laisse un peu de marge pour des pics d'activité sporadiques et évitera d'écraser le processeur.

Voici un peu (plus mais toujours d'actualité) des conseils de l'équipage Weblogic sur cette question: http://docs.oracle.com/cd/E13222_01/wls/docs92/perform/basics.html#wp1132942

Si vous sentez que votre charge est très cohérente et prévisible, vous pouvez pousser cette cible un peu plus, mais à moins que votre La base d'utilisateurs est exceptionnellement tolérante aux réponses lentes périodiques et le budget de votre projet est incroyablement serré. Je vous recommande d'ajouter plus de ressources à votre système (ajout d'un CPU, utilisation d'un CPU avec plus de cœurs, etc.). évincer une autre utilisation du processeur de 10% sur votre plate-forme existante.