AppFlowy AI Your go-to teammate

Proxmox - Virtual Environment  ·
Tino Galante  · Sdtsroonep,0gbfeti608ia164 o2c4lh1g:ivu ermuc7t72m5g5u4nutlc  ·

    🚨 Proxmox + ZFS + SSDs Consommateurs : la correction qui m'a sauvé de 90% de retard d'E/S
    (« Je sais, je sais... n'utilisez pas les lecteurs de consommation dans la production. Les clients achètent ce qu'ils achètent. ”)
    Je publie ça parce que je viens de passer beaucoup trop d'heures à poursuivre un problème de performance qu'une autre pauvre âme va certainement frapper un jour.
    Scénario :
    Hôte Proxmox avec ZFS, quelques SSDs SATA de qualité consommateur (Samsung EVO 870s) et un petit Windows VM.
    Installation simple, rien de fantaisiste.
    Symptôme :
    Copier n'importe quoi - même une ISO - a entraîné un retard d'E/S à monter à 40-90%, le VM a gelé et tout le noeud s'est étouffé.
    Même avec un seul VM et beaucoup de processeur/RAM.
    Je sais, je sais...
    « Vous n'êtes pas censé utiliser les SSDs consommateurs dans la production. ”
    Totalement d'accord.
    Mais parfois, un client choisit le budget qu'il choisit et le travail consiste à le faire fonctionner le plus sûr possible.
    Bref...
    ✔️ La cause racine
    ZFS écritures synchrones + SSDs consommateurs = misère absolue.
    Les SSD SATA consommateurs ont :
    latence fsync lente
    minuscules caches SLC
    aucune protection contre les pertes d'électricité
    performance d'écriture aléatoire horrible une fois que le cache se remplit
    manettes qui peuvent bloquer sous les motifs d'écriture ZFS
    Même avec un miroir à 2 disques, la copie d'un fichier atteindrait la fin du cache SLC → latence SSD sauterait → les flushs ZFS TXG bloqués → le délai d'E/S Proxmox est devenu fou.
    J'ai aussi filé une autre boîte de test à la maison en utilisant des SSD Intel DC Entreprise et aucun de ces problèmes n'est apparu - donc la différence matérielle était la preuve fumante.
    ✔️ La réparation
    Ces réglages d'ensemble de données ZFS ont instantanément stabilisé le système :
    Zfs set synchronisation = désactivé rpool/data
    Zfs set atime = hors rpool/data
    Zfs fixe taille des records = 64K rpool/données
    Ce que chacun fait (version courte) :
    sync = désactivé → empêche ZFS de forcer chaque minuscule écriture à frapper immédiatement le SSD.
    (Oui, léger risque lors d'une perte de puissance inattendue. Nous avons un UPS et un BDR. )
    atime=off → empêche ZFS de faire des écritures de métadonnées pour chaque lecture.
    taille des records = 64K → meilleure taille des blocs pour les charges de travail VM.
    Après ces changements :
    Copies ISO terminées instantanément
    Le délai d'E/S a chuté de 90 % → 1–5 %
    Windows VM est devenu réactif
    Plus de congélation de l'hôte
    Nuit et jour.
    ✔️ Ce que j'ai appris
    RAIDZ1 n'est jamais le bon choix pour les MV sur les SSDs consommateurs
    Même les miroirs peuvent s'étouffer si les SSD ont une mauvaise latence
    SSD d'entreprise (Intel DC, PM883, etc. ) se comportent bien avec ZFS
    SSDs SATA consommateur + écritures de synchronisation ZFS = douleur
    Désactiver la synchronisation est une solution pratique dans le monde réel lorsque vous comprenez les risques et que vous avez un UPS/BDR
    Le délai d'E/S Proxmox est presque toujours un problème de latence de stockage, pas le processeur ou la RAM
    ⭐ Je publie ceci pour que le prochain pauvre administrateur ne perde pas un week-end à cause d'un simple problème de réglage ZFS.
    Si vous exécutez Proxmox sur des SSDs consommateurs (encore une fois, pas idéal), essayez ces paramètres d'ensemble de données.
    Ils pourraient vous éviter des heures de tirage de cheveux.
    Joyeux lapin - et bonne chance là-bas. 💀 🖥️ 🔧
      · Voir l’original
      · Notez cette traduction

Dans environ 6 mois, le prix de RAM et les disques NVME vont augmenter .. de beaucoup.

C'est lié à la demande AI: toutes les capacités mondiales de production basculent vers les mémoires très rentables qui sont utilisées dans les GPUs, et la capacité de production du reste de marché diminuent. Cela augmente ainsi la pression sur les prix sur tous les types de composants de type RAM et disque NVME, pas seulement celle de l'AI.

Chez OVHcloud, on estime que le même serveur produit en Dec 2025 et Dec 2026 coûtera entre +15% et +35% plus cher.

En attendant Juin 2026, la supply chain mondiale anticipe cette augmentation de prix, en réceptionnant les composants 6 mois plutôt, à un prix inférieur, ce qui permet de produire durant 6-12 mois à un prix inférieur vs le vrai prix du marché. Mais ce mouvement défensive fait quand même augmenter les prix des composants dès Dec 2025.

En bref, la conséquence de l'AI sur le Cloud: le prix de certains produits Cloud vont augmenter environ +5 à +10% entre Avril et Septembre 2026. Ce sont les estimations basées sur les informations qu'on dispose en Novembre 2025. Cela peut s'accélérer.

VT Code is a Rust-based terminal coding agent with semantic code intelligence via Tree-sitter. Supports multiple LLM providers with automatic failover and efficient context management.

An Open Source API alternative to NotebookLM's podcast feature: Transforming Multimodal Content into Captivating Multilingual Audio Conversations with GenAI

AI-Bank Statement document automatic by LLM and Personal financial analysis

Custom LangChain Chat Model
LangChain and LangGraph is powerful frameworks for orchestrating language model workflows, but sometimes you need to use a private or proprietary LLM API (for example, your company's internal model, or a paid API with custom authentication). This repository provides working code that builds a custom chat model fully compatible with LangChain and LangGraph APIs.

OpenMemory
Add long-term, semantic, and contextual memory to any AI system.
Open source. Self-hosted. Explainable. Framework-agnostic.

 LLM Inference for Large-Context Offline Workloads
oLLM is a lightweight Python library for large-context LLM inference, built on top of Huggingface Transformers and PyTorch.

Awesome Baremetal est une collection de ressources et outils liés à la gestion de vos serveurs baremeral, avec de nombreux outils plus ou moins connus

git pull origin main
From https://github.com/devnen/chatterbox-tts-server

    branch main -> FETCH_HEAD
    Updating bdedb35..5bf7293
    error: Your local changes to the following files would be overwritten by merge:
    config.yaml
    Please commit your changes or stash them before you merge.
    Aborting

There is no option for me to confirm the merge, and the abortion is automatic.

This is a safety feature in Git. It's stopping because you've made changes to your config.yaml file, and it doesn't want to accidentally delete them.

Here is the easiest and safest way to fix it. Just run these three commands in order:

Save your changes:
git stash

Update the code:
git pull origin main

Get your changes back:
git stash pop

Your files will be updated, and your settings in config.yaml will be safe.