Supervision et Optimisation des Performances d'Artifactory

À mesure que l’utilisation d’Artifactory augmente, ses ressources peuvent progressivement s’épuiser, provoquant des interruptions ou des problèmes de performances. Lorsque l’utilisation augmente, il est d'autant plus important de superviser votre système et ses données historiques. La supervision des schémas d’utilisation est une première étape essentielle pour optimiser Artifactory et assurer sa stabilité. Nous aimerions partager ici avec vous quelques directives et conseils sur la supervision et le réglage d'Artifactory ainsi que de son environnement. Certaines ressources essentielles à superviser (et éventuellement régler) seront abordées, notamment : Tomcat, les connexions HTTP, la base de données, la machine virtuelle Java (JVM) et le stockage.

Tomcat

Artifactory s’exécute sur Tomcat qui utilise le client HTTP Apache pour gérer les requêtes HTTP. Tomcat maintient un pool de threads et alloue un seul thread pour gérer chaque demande entrante. Au fur et à mesure que le pool de threads s’épuise, Tomcat en crée d’autres (jusqu’au maximum spécifié par l'attribut maxThreads) pour gérer les demandes supplémentaires entrantes. Si le nombre de demandes dépasse la valeur maxThreads, les demandes seront mises en file d’attente (jusqu’au maximum spécifié par l’attribut acceptCount). Si ce paramètre est trop élevé, les demandes en attente d’un thread libre peuvent rencontrer des retards jusqu’à ce que les threads deviennent disponibles pour les gérer. Si la limite acceptCount est également atteinte, Tomcat lèvera des erreurs de « connection refused » pour toutes les demandes supplémentaires jusqu’à ce que les ressources requises soient finalement libérées. Toute nouvelle demande, chargement, téléchargement, mise à jour, etc., qui n’a pas pu acquérir de thread échouera. Pour éviter ces problèmes de performances et ces erreurs, vous pouvez augmenter les valeurs de ces attributs dans le fichier server.xml de Tomcat. La valeur par défaut de maxThreads est 200, tandis que acceptCount est défini sur 100. Le fichier d'exemple server.xml ci-dessous affiche des valeurs supérieures pour ces attributs.

<Connector port="8081" acceptCount="200" compression="off" connectionLinger="-1" connectionTimeout="60000" maxThreads="600" acceptorThreadCount="2" enableLookups="false"/>

Supervision

Netstat : Si vous n’avez pas d’outils de supervision configurés, vous pouvez facilement surveiller l’utilisation de votre connexion HTTP en direct en exécutant la commande netstat ci-dessous (remplacez TOMCAT_PORT par votre port tomcat dans Artifactory).

while sleep 5; do printf "$(date)  HTTP Connections: $(netstat -latuen | grep TOMCAT_PORT | wc -l)"; echo; done

Vous pouvez également spécifier l’état que vous souhaitez compter. Par exemple, vous pouvez compter le nombre d’états ESTABLISHED en exécutant la commande suivante (remplacez TOMCAT_PORT par votre port Tomcat dans Artifactory)

while sleep 5; do printf "$(date)  HTTP Connections : $(netstat -latuen | grep TOMCAT_PORT | grep ESTABLISHED | wc -l)"; echo; done

 

MBean pour les connexions HTTP : À partir de la version 4.12, Artifactory a exposé la connexion HTTP MBean afin que son utilisation puisse être suivie. Ce MBean se trouve dans chaque dépôt sous : 

org.jfrog.artifactory > Artifactory | HTTPConnectionPool > [Repo Name]: Attributs

Pour en savoir plus, lisez notre billet de blog sur l'Intégration d'Artifactory MBeans.

 

Outils tiers : Un certain nombre d’outils tiers peuvent également être utilisés pour superviser les connexions HTTP et diverses autres ressources. La base de connaissances de JFrog contient des instructions pour certains de ces outils, notamment JConsole, JavaMelody et Nagios. Pour le conteneur Docker Artifactory, il existe plusieurs outils open source qui peuvent être utilisés pour superviser les connexions HTTP, l’utilisation de la machine virtuelle Java, etc.

Le graphique ci-dessous a été généré avec un autre outil nommé LogicMonitor. Il montre clairement que le nombre maximal de threads disponibles dans Tomcat a été atteint et est un bon indicateur montrant que vous devriez envisager d’augmenter l’attribut maxThreads dans le fichier server.xml de Tomcat.

Connexions HTTP pour Artifactory

Par défaut, le nombre de connexions HTTP autorisées par dépôt est défini sur 50. Si vous remarquez que le nombre de connexions utilisées approche ou atteint systématiquement cette valeur, vous pouvez l’augmenter à l’aide du paramètre suivant dans le fichier $ARTIFACTORY_HOME/etc/artifactory.system.properties :

artifactory.http.client.max.total.connections = {value}

Connexions HTTP si vous utilisez S3

Si vous utilisez le magasin d’objets S3 pour gérer votre filestore, vous devez savoir que le fournisseur binaire S3 d’Artifactory est implémenté à l’aide de la bibliothèque Jets3t qui définit le nombre maximal de connexions simultanées, autorisées à 100 par défaut. Dans le cadre d’une activité intensive avec le filestore qui nécessite de nombreuses connexions au magasin d’objets S3, vous pouvez constater que les demandes restent en attente pour une connexion à partir du pool de connexions JetS3t. Pour éviter ce scénario, vous devez ajouter la propriété httpclient.max-connections pour le fournisseur binaire S3 dans votre fichier $ARTIFACTORY_HOME/etc/binarystore.xml. L’extrait de code ci-dessous est un exemple de modèle Cleversafe extrait du Guide Utilisateur Artifactory qui montre comment définir la propriété httpclient.max-connections :

<config version="v1">
    <chain template="s3"/>
    <provider id="s3" type="s3">
        <identity>XXXXXXXXX</identity>
        <credential>XXXXXXXX</credential>    
        <endpoint>[My CleverSafe Server]</endpoint>
        <bucketName>[My CleverSafe Bucket]</bucketName>
        <property name="httpclient.max-connections" value="300"/>
        <httpsOnly>false</httpsOnly>
        <property name="s3service.disable-dns-buckets" value="true"></property>                              
    </provider>
</config>

Pour plus d’informations sur le réglage de Tomcat, Netflix offre des informations précieuses sur son blog, Tuning Tomcat For A High Throughput, Fail Fast System .

Connexions HTTP pour le Reverse Proxy

Si vous utilisez un reverse proxy devant votre Artifactory, vous pouvez remarquer que le nombre de connexions HTTP atteint sa valeur maximale, empêchant ces connexions d’atteindre Artifactory. Dans ce cas, vous devez envisager d’allouer plus de connexions à votre reverse proxy. Pour obtenir des instructions détaillées sur la procédure à suivre, lisez la documentation du serveur reverse proxy que vous utilisez. Vous pouvez en savoir plus sur le Réglage de NGINX pour favoriser les performances sur le blog NGINX. Pour Apache, vous pouvez vous référer à Apache Performance Tuning dans la documentation Apache. De même, vous pouvez vous référer à cette documentation Apache pour le reverse proxy Apache HTTPD.

Base de données

Le nombre de connexions de base de données est une autre ressource essentielle qui doit être supervisée lors de l’optimisation d’Artifactory. Les administrateurs doivent être en mesure de confirmer que le nombre de connexions de base de données disponible est suffisant. Sinon, les utilisateurs peuvent rencontrer des demandes en attente de connexions libres. Le nombre de connexions de base de données autorisées doit être réglé en fonction de l’utilisation actuelle, mais gardez à l’esprit que cette valeur ne doit jamais dépasser le nombre maximal de connexions de base de données configurées dans la base de données elle-même.

Supervision

Artifactory expose également un MBean pour les Connexions de base de données, afin que vous puissiez les superviser à l’aide de n’importe quel outil compatible JMX. Si vous utilisez JConsole, ce MBean est disponible sous : org.jfrog.artifactory > Artifactory > Storage: Data Source. Naturellement, il existe de nombreux autres outils que vous pouvez utiliser pour superviser vos connexions de base de données. Par exemple, le graphique ci-dessous montre un pic d’utilisation de la base de données enregistré par l'outil de supervision AWS de la base de données RDS.

Netstat peut également être utilisé ici pour superviser les connexions de base de données actives (remplacez DB_PORT par votre port de base de données dans Artifactory) :

while sleep 5; do printf "$(date)  DB Connections: $(netstat -latuen | grep DB_PORT  | wc -l)"; echo; done

Vous pouvez également spécifier l’état que vous souhaitez compter. Par exemple, vous pouvez compter le nombre d’états LISTEN en exécutant la commande suivante (remplacez DB_PORT par votre port de base de données dans Artifactory) :

while sleep 5; do printf "$(date)  DB Connections: $(netstat -latuen | grep DB_PORT  | grep LISTEN| wc -l)"; echo; done

Si vous constatez que vos connexions de base de données sont constamment proches de la valeur maximale, vous devrez probablement augmenter celle-ci. Si le nombre de connexions de base de données actives atteint la valeur maximale et que davantage de connexions de base de données sont demandées, le journal du serveur Artifactory ( $ARTIFACTORY_HOME/logs/artifactory.log) génère l’exception suivante :

org.springframework.transaction.CannotCreateTransactionException: Could not open JDBC Connection for transaction; nested exception is org.apache.tomcat.jdbc.pool.PoolExhaustedException: [art-exec-672866] Timeout: Pool empty. Unable to fetch a connection in 120 seconds, none available[size:100; busy:100; idle:0; lastwait:120000].

Vous pouvez également constater une dégradation des performances en raison du nombre accru de connexions de base de données qui attendent d’obtenir leur place dans la file d’attente inactive (pool.max.idle, ce qui est expliqué dans la section suivante). Vous pouvez le confirmer en effectuant un thread dump et en recherchant le nombre de threads qui sont mis de côté : org.apache.tomcat.jdbc.pool.ConnectionPool.returnConnection.

Réglage

Dans Artifactory : les connexions à la base de données d’Artifactory peuvent être configurées en définissant les paramètres suivants dans le fichier $ARTIFACTORY_HOME/etc/db.properties :

• pool.max.active : le nombre maximal de connexions de base de données simultanées autorisées (la valeur par défaut est 100)
• pool.max.idle : le nombre maximal de connexions de base de données inactives qu’Artifactory contiendra (la valeur par défaut est 10)

Dans la base de données : il est tout aussi important d’augmenter le nombre de connexions dans la base de données elle-même. Reportez-vous à la documentation de la base de données que vous utilisez. En plus de superviser et de modifier les connexions de base de données, d’autres paramètres entrent en jeu en ce qui concerne les performances de la base de données. Si vous souhaitez obtenir quelques exemples de réglage, notre documentation MySQL inclut des suggestions pour votre fichier my.cnf, afin que vous puissiez régler MySQL pour obtenir des performances optimales. Pour PostgreSQL, vous pouvez en savoir plus sur le réglage dans le wiki PostgreSQL où vous pouvez également en savoir plus sur la façon d'augmenter votre paramètre max_connections.

Mémoire JVM

Lorsque vous optimisez Artifactory, vous devez également prendre en compte la mémoire. Si la mémoire allouée à Artifactory est insuffisante, un certain nombre de problèmes peuvent survenir, tels qu’une interface utilisateur lente, des réponses lentes et, dans le pire des cas, une absence de réponse totale d'Artifactory. Pour éviter de vous heurter à des problèmes de consommation de mémoire, vous pouvez modifier les paramètres de la machine virtuelle Java Artifactory.

Supervision

Lors de la supervision des données historiques de l’utilisation de la JVM, notez qu'il est important de rendre la taille de heap initiale (Xms) inférieure à la taille de heap maximale (Xmx). Sinon, il sera difficile de voir les schémas d’utilisation dans les graphiques.

Un certain nombre d’outils évoqués plus haut (par exemple, JConsole, JVisualVM, Javamelody, etc.) peuvent également être utilisés pour superviser l’utilisation de la JVM.

Réglage

Étant donné que le nombre d’utilisateurs et la taille des dépôts ont un impact direct sur l’utilisation et les performances de la mémoire, lors de l’optimisation d’Artifactory, nous vous recommandons de consulter les directives sur le matériel recommandé dans le Guide Utilisateur Artifactory lorsque vous modifiez des paramètres de la JVM. Pour modifier l'attribution de mémoire de la JVM, veuillez vous reporter aux instructions correspondantes pour Linux, Solaris ou Mac, ou Windows.

Stockage  

Le stockage est une autre ressource importante qui doit être supervisée, car un manque de stockage peut nuire aux performances et à la stabilité.

Supervision

Taux d’E/S disque : un taux d’E/S disque lent peut entraîner une dégradation significative des performances, mais vous pouvez utiliser différents outils pour superviser cela. Dans l’exemple ci-dessous, iostat est utilisé pour superviser le taux d’E/S. Nous vous recommandons d’effectuer ce test avant d’installer/de configurer une instance Artifactory. Ajoutez l’indicateur -d pour afficher uniquement la page d’informations sur l’appareil et -x pour obtenir des informations détaillées (statistiques de lecture/écriture distinctes). Ajoutez 1 pour une sortie continue. Voici un exemple de sortie :

$ iostat -dx 1

Device:         rrqm/s   wrqm/s     r/s     w/s    rkB/s    wkB/s avgrq-sz avgqu-sz   await r_await w_await  svctm  %util

xvdb              0.00     0.00  649.00    0.00 55808.00     0.00   171.98     8.13   12.44   12.44    0.00   1.54 100.00

 

Espace disque : Artifactory expose un MBean qui vous permet de superviser le Stockage, qui se trouve sous org.jfrog.artifactory > Artifactory > Storage. Pour les installations Enterprise, JFrog Mission Control fournit un tableau de bord central à partir duquel vous pouvez superviser le stockage (et plus encore) de toutes vos instances Artifactory globales en un seul endroit. Vous pouvez en savoir plus sur l’utilisation de Mission Control pour suivre l’utilisation du stockage dans ce billet de blog.

Réglage

Si vous trouvez que votre filestore existant (par exemple, S3, NFS, etc.) est lent, et si vous avez également un filestore local qui est plus rapide et plus petit (par exemple, un disque SSD), alors cache-fs dans Artifactory peut vous aider. Cachefs fonctionne comme un système de fichiers, mais dispose également d’un cache binaire LRU (Least Recently Used) pour les demandes de chargement et de téléchargement. L’activation de Cachefs peut améliorer considérablement les performances des instances possédant des IOPS (opérations d’E/S) élevées ou un accès NFS lent. Pour plus d’informations sur la configuration de cette option, reportez-vous à la section Cached Filesystem Binary Provider dans le Guide Utilisateur Artifactory.

Si vous constatez que votre disque est à court d’espace, vous pouvez déplacer le filestore actuel vers une nouvelle solution de stockage. Une option consiste à utiliser l’un des fournisseurs de stockage Cloud pris en charge (S3, GCS ou Azure) pour obtenir un stockage massivement scalable. Une autre option consiste à ajouter du stockage à l’aide de la fonctionnalité de sharding de filestore d’Artifactory, que vous pouvez configurer pour utiliser une configuration redondante ou non redondante afin d’obtenir un filestore stable, fiable et évolutif. Pour plus de conseils sur l'ajustement de la manière dont Artifactory utilise l’espace disque, consultez le Guide Utilisateur.

 

Généralement, lorsqu’il s’agit d’optimiser Artifactory, une approche universelle ne convient pas à tous. En surveillant votre configuration, vous pouvez modifier votre système et vos paramètres de la manière appropriée afin que votre instance Artifactory puisse atteindre ses performances optimales. Nous vous recommandons également d’effectuer des tests de contrainte pour le réglage. Vous pouvez utiliser Artifactory Query Language (AQL) ou JFrog CLI pour tester les téléchargements et téléchargements simultanés, et utiliser l’option « –threads » de l’interface de ligne de commande pour tester les téléchargements et téléchargements multithread.