De combien de RAM WordPress a-t-il besoin ?

WordPress lui-même a peu besoin de mémoire, et ses exigences officielles ne donnent aucun chiffre de RAM. Pour un petit site, 1 à 2 Go de RAM sont généralement un bon point de départ (une règle empirique qui varie selon le site). Les boutiques, de nombreuses extensions et un trafic important peuvent porter le besoin à 4 Go ou plus.

Ce dont vous avez réellement besoin dépend du type de site : les extensions, le trafic, la taille de la base de données et l'activation ou non du cache. Cet article présente les chiffres officiels, ce qui consomme de la mémoire, et comment repérer qu'elle ne suffit pas.

Que disent les exigences officielles ?

La page des exigences d'hébergement de WordPress.org (une recommandation officielle) demande PHP 8.3 ou plus récent, MariaDB 10.11 ou MySQL 8.0 ou plus récent, et la prise en charge de HTTPS. Elle recommande Apache ou Nginx comme serveur web. La page ne donne aucun chiffre pour la RAM. Des versions plus anciennes comme PHP 7.4 et MySQL 5.5.5 fonctionnent encore, mais la page note qu'elles ont atteint la fin de vie et présentent des risques de sécurité. Pour une nouvelle installation, choisissez les versions recommandées.

Les seuls chiffres officiels sur la mémoire sont les limites que PHP accorde à WordPress. Sur une installation à site unique, la valeur par défaut de WP_MEMORY_LIMIT est de 40 Mo, et de 64 Mo en multisite. L'espace d'administration utilise WP_MAX_MEMORY_LIMIT, que le cœur de WordPress tente de porter à 256 Mo par défaut. Ce sont des plafonds pour une seule requête PHP, pas la RAM totale du serveur. Vous pouvez vérifier les valeurs applicables à votre site sous Tools > Site Health > Info : la limite de mémoire PHP figure dans la section Server, tandis que WP_MEMORY_LIMIT et WP_MAX_MEMORY_LIMIT apparaissent dans la section WordPress Constants.

Qu'est-ce qui consomme vraiment la RAM ?

• Les processus PHP. Chaque requête simultanée lance un processus PHP. Avec PHP-FPM, pm.max_children limite le nombre de processus actifs en même temps (voir le manuel PHP). Selon les extensions, un processus peut utiliser de quelques dizaines à plusieurs centaines de mégaoctets. C'est une observation générale, qui diffère d'un site à l'autre.
• La base de données. MariaDB ou MySQL garde en mémoire les données lues souvent. Les gros sites riches en extensions en demandent davantage.
• Le cache du système d'exploitation. Linux utilise la mémoire libre comme cache de disque. Voir peu de mémoire libre dans la sortie de free -h n'est pas un problème. Regardez plutôt la colonne available.
• Les couches de cache. Un cache d'objets (comme Redis) réduit les requêtes à la base de données, mais il occupe lui-même de la mémoire.

Voici un exemple simple. Sur un serveur de 2 Go de RAM, si vous réservez environ 1 Go au système d'exploitation et à la base de données, il reste 1 Go pour PHP. Si un processus PHP utilise 100 Mo en moyenne, garder pm.max_children autour de 10 est raisonnable. Ces chiffres montrent seulement comment se fait le calcul. Vos propres mesures peuvent donner autre chose.

Taille de départ selon le type de site

Ces valeurs sont des règles empiriques. Elles varient selon les extensions et le trafic, et ne sont pas une promesse ferme.

Si vous montez une boutique, lisez aussi notre article « Choisir un serveur pour WooCommerce ».

Que voit-on quand la RAM s'épuise ?

• Le site renvoie de temps en temps une erreur 502 ou 503. PHP-FPM ou le serveur web ne parvient pas à répondre.
• Un message « Error establishing a database connection » apparaît. La base de données a peut-être été arrêtée faute de mémoire.
• L'espace d'administration devient très lent, et les mises à jour d'extensions ou les envois d'images restent bloqués à mi-chemin.

Pour confirmer, connectez-vous au serveur et lancez ces commandes :

free -h

sudo journalctl -k | grep -i -E "out of memory|oom-kill"

La seconde commande liste les événements où le noyau a arrêté un programme faute de mémoire. Si elle affiche des lignes, la RAM ne suffit pas. Dans top, appuyez sur Maj+M pour voir les processus qui utilisent le plus de mémoire.

Ce que vous pouvez essayer avant d'augmenter la taille

1. Mettez en place un cache de pages, sous forme d'extension ou côté serveur. Une page servie depuis le cache n'exécute ni PHP ni la base de données.
2. Supprimez les extensions que vous n'utilisez pas. Chaque extension active charge son code à chaque requête.
3. Ajustez pm.max_children dans PHP-FPM à votre mémoire. En gros, divisez la mémoire que vous pouvez donner à PHP par la mémoire moyenne d'un processus PHP. Une valeur trop élevée consomme la mémoire sous charge.
4. Une petite zone de swap évite que le serveur plante lors de brefs pics. Mais le swap se trouve sur le disque et il est lent : il ne remplace pas la RAM.

Si vous avez tout essayé et que la mémoire se remplit encore, il est temps d'augmenter la taille. Mesurez d'abord : le problème apparaît-il aux heures de pointe, ou toute la journée ? Comme seuil général, envisagez d'augmenter si la mémoire available tombe souvent sous 10 à 15 % de la RAM totale aux heures de pointe, ou si le swap est constamment utilisé. Ce n'est pas une règle stricte, seulement un point de départ.

Augmenter la taille depuis le panneau

Dans le panneau Seturack, vous augmentez la taille du serveur avec le curseur de l'onglet Taille. Après le paiement, le serveur redémarre une fois tout seul, et votre adresse IP et vos données restent les mêmes. Commencer avec une petite taille est donc une voie sûre. Un serveur avec WordPress préinstallé est prêt en 3,5 à 4 minutes environ. Jetez un œil à la page du serveur WordPress.