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.
Commentaires
ksimon
Membre depuis le 19/05/2024
première chose passe en gp3 sur tes instances gp2 tu peux paramétrer les iops et le throughput indépendamment et ça coûte bcp moins cher pour des perf équivalentes ou meilleures. surtout si tes iops sont pas au max sur gp2
marianne-laporte
Membre depuis le 21/07/2024
audit tes bases aussi tu as ptete des tables orphelines des indexes inutiles ou des logs qui prennent bcp de place. vacuum full sur postgres peut aider à récupérer de l'espace mais ça locke la table
godard-antoinette
Membre depuis le 29/04/2024
regarde aussi les types d'instances des fois on surdimensionne. tu peux utiliser performance insights pour voir si ta base est vraiment limitée par le cpu ou la ram ou les iops. et envisager des reserved instances pour les grosses bases stables sur 1 ou 3 ans c'est une économie massive
brigitte33
Membre depuis le 27/06/2024
gp3 c'est noté je vais tester ça. pour les reserved instances on y pense mais faut voir la pérennité des projets. et oui l'audit des tables c'est un bon point on a du legacy qui traîne. merci pour les tips je vais mettre ça en place
ksimon
Membre depuis le 19/05/2024
et un truc con mais le monitoring aws cloudwatch sur les métriques rds cpu iops connexions actives etc pour identifier les périodes de sous-utilisation ou les pics anormaux tu pourrais ptete réduire l'instance size pendant les heures creuses si t'as une infra serverless derrière
brigitte33
Membre depuis le 27/06/2024
ouais le monitoring on fait déjà mais pas assez en mode "finops" je vais plus creuser les stats pour le sizing. merci pour les retours