devopssec
n'est en aucun cas responsable du contenu généré par l'utilisateur. Le contenu posté
exprime les opinions de leur auteur seulement.
Les textes et messages publiés sont la propriété de ceux qui les postent.
je fais de mon mieux pour modérer les propos inappropriés qui pourraient être postés ici,
mais je me dégage de toute responsabilité sur ce que vous postez.
Vous demeurez le seul responsable de vos actes et de vos messages au regard de la loi.
Vous acceptez de ne pas utiliser le service pour poster ou lier vers un contenu qui est
diffamatoire, injurieux, haineux, menaçant, spams ou pourriels, étant de nature à offenser,
ayant un contenu réservé aux adultes ou répréhensible, contenant des renseignements
personnels des autres, risquant de violer les droits d'auteurs, encourageant une activité
illégale ou contraire à toutes les lois.
Le respect est la principale qualité de notre communauté. En conséquence, veillez à l'être envers
vos camarades ici présents, en particulier les nouveaux membres qui comme vous, cherchent
à découvrir l'univers DEVOPS, et n'ont pas toutes vos connaissances.
Tout manque de respect à l'encontre d'un membre, néophyte ou non, entraînera également des sanctions,
à savoir avertissements, bannissements voire poursuites selon la gravité de la situation.
devopssec
décline toute responsabilité concernant les rencontres réelles.
navarro-eleonore
Membre depuis le 16/02/2025
pour les environnements virtuels comme aws ebs où le backend de stockage est déjà optimisé par l'hyperviseur le scheduler
noopest souvent le meilleur choix car il ne fait rien de plus et laisse l'hyperviseur gérer la réorganisation des i/omarine-guillou
Membre depuis le 24/08/2024
noopc'est pas mal mais si t'es sur un kernel un peu plus récent (genre 5.x) lemq-deadline(multi-queue deadline) est aussi très efficace pour les nvme c'est un bon compromis pour pas mal de workloads car il gère mieux les priorités en lecture/écriturerenee-sanchez
Membre depuis le 21/03/2025
avant de toucher au scheduler t'es sûr que c'est pas le
burst balancede tesgp3qui est à zéro ? si tu as tapé dans tes iops max pendant trop longtemps tes volumes peuvent être throttlés par aws et aucun scheduler ne pourra te sauvermaillet-elodie
Membre depuis le 21/07/2024
et ton workload c'est quoi plus de lecture ou d'écriture des petites i/o random ou des grosses i/o séquentielles pour des bases de données genre
rdsou des fichiers logs ? ça peut changer pas mal la donne pour le choix du schedulerpaul54
Membre depuis le 23/10/2024
aussi check tes
mount optionssurtout lenoatimeourelatimeça peut réduire les écritures inutiles sur les métadonnées et soulager l'i/o et lefstabbien sûrsmarques
Membre depuis le 02/07/2024
ok je retiens
noopetmq-deadline. pour le burst balance j'ai checké c'est ok. le workload c'est majoritairement de la petite écriture random type logs et des lectures occasionnelles. lesmount optionssont déjà okje vais tester
mq-deadlined'abord puisnooppour voir la différence suriostat. merci pour les tips ça éclaire ma lanterne