La Fibre
Hébergeurs et opérateurs pro / entreprises => Hébergeurs et opérateurs pro / entreprises => 
Scaleway => Discussion démarrée par: vivien le 03 novembre 2016 à 19:57:03
-
J'ai le disque dur de mon serveur (LaFibre.info) vient de me lâcher (je n'ai pas mis de RAID) après 4ans et demi de bon services. La partition /home est passé en read-only (donc plus de graphe SmokePing).
La base de donnée MySQL du forum est sur la partition / donc c'est encore bon (j'ai une sauvegarde quotidienne si cela plantait)
J'envisage donc de me déplacer Lundi à Maxnod pour changer le disque dur et faire comme j'avais prévu dés le départ : mettre un SSD qui me semble nettement plus fiable, vu le volume journalier écrit sur le disque.
J'ai vu que OVH utilise des SSD Intel DC S3K (https://www.ovh.com/fr/serveurs_dedies/avantages-disques-ssd.xml) (pour Centre de données), probablement la série S3520. Ils sont cher et je ne trouve pas le modèle 400 Go sur Paris (je ne vais pas le commander sur Internet, vu le besoin urgent)
J'ai vu que Ikoula utilisait des SSD Kingston SKC100S.
Quels SSD utilise Online ?
Je suis preneur de vos conseils.
Pour info les log du serveur : (la partition / n'est pas touchée)
[866541.714423] ata1.00: exception Emask 0x0 SAct 0x7fffffff SErr 0x0 action 0x0
[866541.714890] ata1.00: irq_stat 0x40000008
[866541.715147] ata1.00: failed command: READ FPDMA QUEUED
[866541.715448] ata1.00: cmd 60/00:58:00:f3:44/02:00:21:00:00/40 tag 11 ncq 262144 in
[866541.715448] res 41/40:00:b9:f4:44/00:00:21:00:00/40 Emask 0x409 (media error) <F>
[866541.716336] ata1.00: status: { DRDY ERR }
[866541.716565] ata1.00: error: { UNC }
[866541.719387] ata1.00: configured for UDMA/133
[866541.719421] sd 0:0:0:0: [sda] tag#11 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[866541.719426] sd 0:0:0:0: [sda] tag#11 Sense Key : Medium Error [current] [descriptor]
[866541.719429] sd 0:0:0:0: [sda] tag#11 Add. Sense: Unrecovered read error - auto reallocate failed
[866541.719434] sd 0:0:0:0: [sda] tag#11 CDB: Read(10) 28 00 21 44 f3 00 00 02 00 00
[866541.719436] blk_update_request: I/O error, dev sda, sector 558167225
[866541.719817] ata1: EH complete
[866543.766435] ata1.00: exception Emask 0x0 SAct 0x78 SErr 0x0 action 0x0
[866543.766803] ata1.00: irq_stat 0x40000001
[866543.767027] ata1.00: failed command: READ FPDMA QUEUED
[866543.767323] ata1.00: cmd 60/08:18:b8:f4:44/00:00:21:00:00/40 tag 3 ncq 4096 in
[866543.767323] res 41/40:00:b9:f4:44/00:00:21:00:00/40 Emask 0x409 (media error) <F>
[866543.768196] ata1.00: status: { DRDY ERR }
[866543.768425] ata1.00: error: { UNC }
[866543.768626] ata1.00: failed command: READ FPDMA QUEUED
[866543.768920] ata1.00: cmd 60/08:20:08:90:c1/00:00:02:00:00/40 tag 4 ncq 4096 in
[866543.768920] res 41/40:00:00:00:00/00:00:00:00:00/00 Emask 0x9 (media error)
[866543.769763] ata1.00: status: { DRDY ERR }
[866543.769993] ata1.00: error: { UNC }
[866543.778411] ata1.00: failed command: WRITE FPDMA QUEUED
[866543.786744] ata1.00: cmd 61/70:28:40:e2:1a/00:00:1f:00:00/40 tag 5 ncq 57344 out
[866543.786744] res 41/40:00:00:00:00/00:00:00:00:00/00 Emask 0x9 (media error)
[866543.819822] ata1.00: status: { DRDY ERR }
[866543.828309] ata1.00: error: { UNC }
[866543.836641] ata1.00: failed command: READ FPDMA QUEUED
[866543.844664] ata1.00: cmd 60/08:30:48:66:b4/00:00:02:00:00/40 tag 6 ncq 4096 in
[866543.844664] res 41/40:00:00:00:00/00:00:00:00:00/00 Emask 0x9 (media error)
[866543.877429] ata1.00: status: { DRDY ERR }
[866543.885795] ata1.00: error: { UNC }
[866543.896239] ata1.00: configured for UDMA/133
[866543.896266] sd 0:0:0:0: [sda] tag#3 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[866543.896271] sd 0:0:0:0: [sda] tag#3 Sense Key : Medium Error [current] [descriptor]
[866543.896274] sd 0:0:0:0: [sda] tag#3 Add. Sense: Unrecovered read error - auto reallocate failed
[866543.896278] sd 0:0:0:0: [sda] tag#3 CDB: Read(10) 28 00 21 44 f4 b8 00 00 08 00
[866543.896281] blk_update_request: I/O error, dev sda, sector 558167225
[866543.904646] sd 0:0:0:0: [sda] tag#4 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[866543.904649] sd 0:0:0:0: [sda] tag#4 Sense Key : Medium Error [current] [descriptor]
[866543.904652] sd 0:0:0:0: [sda] tag#4 Add. Sense: Unrecovered read error - auto reallocate failed
[866543.904655] sd 0:0:0:0: [sda] tag#4 CDB: Read(10) 28 00 02 c1 90 08 00 00 08 00
[866543.904657] blk_update_request: I/O error, dev sda, sector 46239752
[866543.912758] sd 0:0:0:0: [sda] tag#5 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[866543.912761] sd 0:0:0:0: [sda] tag#5 Sense Key : Medium Error [current] [descriptor]
[866543.912763] sd 0:0:0:0: [sda] tag#5 Add. Sense: Unrecovered read error - auto reallocate failed
[866543.912766] sd 0:0:0:0: [sda] tag#5 CDB: Write(10) 2a 00 1f 1a e2 40 00 00 70 00
[866543.912768] blk_update_request: I/O error, dev sda, sector 521855552
[866543.920925] sd 0:0:0:0: [sda] tag#6 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[866543.920929] sd 0:0:0:0: [sda] tag#6 Sense Key : Medium Error [current] [descriptor]
[866543.920932] Aborting journal on device sda6-8.
[866543.920933] sd 0:0:0:0: [sda] tag#6 Add. Sense: Unrecovered read error - auto reallocate failed
[866543.920936] sd 0:0:0:0: [sda] tag#6 CDB: Read(10) 28 00 02 b4 66 48 00 00 08 00
[866543.920938] blk_update_request: I/O error, dev sda, sector 45377096
[866543.920999] ata1: EH complete
[866545.766393] ata1.00: exception Emask 0x0 SAct 0x40000 SErr 0x0 action 0x0
[866545.774239] ata1.00: irq_stat 0x40000008
[866545.782205] ata1.00: failed command: READ FPDMA QUEUED
[866545.790198] ata1.00: cmd 60/08:90:b8:f4:44/00:00:21:00:00/40 tag 18 ncq 4096 in
[866545.790198] res 41/40:00:b9:f4:44/00:00:21:00:00/40 Emask 0x409 (media error) <F>
[866545.822176] ata1.00: status: { DRDY ERR }
[866545.830152] ata1.00: error: { UNC }
[866545.840042] ata1.00: configured for UDMA/133
[866545.840056] sd 0:0:0:0: [sda] tag#18 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
[866545.840060] sd 0:0:0:0: [sda] tag#18 Sense Key : Medium Error [current] [descriptor]
[866545.840062] sd 0:0:0:0: [sda] tag#18 Add. Sense: Unrecovered read error - auto reallocate failed
[866545.840066] sd 0:0:0:0: [sda] tag#18 CDB: Read(10) 28 00 21 44 f4 b8 00 00 08 00
[866545.840068] blk_update_request: I/O error, dev sda, sector 558167225
[866545.848092] ata1: EH complete
[866545.914569] EXT4-fs error (device sda6): ext4_journal_check_start:56: Detected aborted journal
[866545.931054] EXT4-fs (sda6): Remounting filesystem read-only
[866545.983572] EXT4-fs error (device sda6): ext4_journal_check_start:56: Detected aborted journal
[866546.058559] EXT4-fs error (device sda6): ext4_journal_check_start:56: Detected aborted journal
J'ai lancé un test long avec smartctl, voici le résultat :
# smartctl -a /dev/sda
smartctl 6.2 2013-07-26 r3841 [x86_64-linux-4.4.0-45-generic] (local build)
Copyright (C) 2002-13, Bruce Allen, Christian Franke, www.smartmontools.org
=== START OF INFORMATION SECTION ===
Model Family: Western Digital RE4
Device Model: WDC WD5003ABYX-18WERA0
Serial Number: WD-WMAYP2673375
LU WWN Device Id: 5 0014ee 0adb65668
Add. Product Id: DELL(tm)
Firmware Version: 01.01S02
User Capacity: 500 107 862 016 bytes [500 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: 7200 rpm
Device is: In smartctl database [for details use: -P show]
ATA Version is: ATA8-ACS (minor revision not indicated)
SATA Version is: SATA 2.6, 3.0 Gb/s
Local Time is: Thu Nov 3 18:41:28 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
=== START OF READ SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED
General SMART Values:
Offline data collection status: (0x85) Offline data collection activity
was aborted by an interrupting command from host.
Auto Offline Data Collection: Enabled.
Self-test execution status: ( 117) The previous self-test completed having
the read element of the test failed.
Total time to complete Offline
data collection: ( 7680) seconds.
Offline data collection
capabilities: (0x7b) SMART execute Offline immediate.
Auto Offline data collection on/off support.
Suspend Offline collection upon new
command.
Offline surface scan supported.
Self-test supported.
Conveyance Self-test supported.
Selective Self-test supported.
SMART capabilities: (0x0003) Saves SMART data before entering
power-saving mode.
Supports SMART auto save timer.
Error logging capability: (0x01) Error logging supported.
General Purpose Logging supported.
Short self-test routine
recommended polling time: ( 2) minutes.
Extended self-test routine
recommended polling time: ( 82) minutes.
Conveyance self-test routine
recommended polling time: ( 5) minutes.
SCT capabilities: (0x303f) SCT Status supported.
SCT Error Recovery Control supported.
SCT Feature Control supported.
SCT Data Table supported.
SMART Attributes Data Structure revision number: 16
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
1 Raw_Read_Error_Rate 0x002f 200 200 051 Pre-fail Always - 3
3 Spin_Up_Time 0x0027 142 141 021 Pre-fail Always - 3900
4 Start_Stop_Count 0x0032 100 100 000 Old_age Always - 23
5 Reallocated_Sector_Ct 0x0033 200 200 140 Pre-fail Always - 0
7 Seek_Error_Rate 0x002e 200 200 000 Old_age Always - 0
9 Power_On_Hours 0x0032 092 092 000 Old_age Always - 6051
10 Spin_Retry_Count 0x0032 100 253 000 Old_age Always - 0
11 Calibration_Retry_Count 0x0032 100 253 000 Old_age Always - 0
12 Power_Cycle_Count 0x0032 100 100 000 Old_age Always - 21
192 Power-Off_Retract_Count 0x0032 200 200 000 Old_age Always - 14
193 Load_Cycle_Count 0x0032 200 200 000 Old_age Always - 8
194 Temperature_Celsius 0x0022 110 100 000 Old_age Always - 33 (Min/Max 33/35)
196 Reallocated_Event_Count 0x0032 200 200 000 Old_age Always - 0
197 Current_Pending_Sector 0x0032 200 200 000 Old_age Always - 2
198 Offline_Uncorrectable 0x0030 200 200 000 Old_age Offline - 1
199 UDMA_CRC_Error_Count 0x0032 200 200 000 Old_age Always - 0
200 Multi_Zone_Error_Rate 0x0008 200 200 000 Old_age Offline - 4
SMART Error Log Version: 1
No Errors Logged
SMART Self-test log structure revision number 1
Num Test_Description Status Remaining LifeTime(hours) LBA_of_first_error
# 1 Extended offline Completed: read failure 50% 6050 558173231
# 2 Short offline Completed without error 00% 2 -
# 3 Extended offline Completed without error 00% 2 -
SMART Selective self-test log data structure revision number 1
SPAN MIN_LBA MAX_LBA CURRENT_TEST_STATUS
1 0 0 Not_testing
2 0 0 Not_testing
3 0 0 Not_testing
4 0 0 Not_testing
5 0 0 Not_testing
Selective self-test flags (0x0):
After scanning selected spans, do NOT read-scan remainder of disk.
If Selective self-test is pending on power-up, resume after 0 minute delay.
PS : Plus de graphe SmokePing jusqu'au remplacement du disque.
-
J'ai vu que Ikoula utilisait des SSD Kingston SKC100S.
C'est la gamme entreprise de Kingston.
Grosbill propose 4 modèles Kingston de 480 Go (HyperX HyperX Savage 480 Go / KINGSTON SSD V300 - 480 Go - SATA III / KINGSTON HyperX Fury - 480 Go / KINGSTON SSD UV400 - 480 Go - SATA III) mais ce sont 4 modèles pour le grand public avec un over-provisioning assez faible.
-
Si le problème c'est l'overprovisionning, tu peux le faire manuellement en ne partitionnant pas la totalité. Je te renvoie à cet article (http://www.hardware.fr/articles/906-16/tenue-performances.html) pour plus de détails sur la tenue des performances en fonction de ce que tu décide de provisionner.
Par contre si c'est plus pour la fiabilité, alors il vaut mieux partir sur une gamme professionnelle comme prévu initialement, plutôt de Samsung/Intel/Micron/Kingston je dirai pour leur réputation.
-
Merci de l'astuce.
Je vais peut-être partir sur un Samsung 850 Pro 512 Go avec garantie de 10ans.
Je vois qu'il intègre un logiciel pour augmenter l'overprovisioning (qui ne dois probablement fonctionne qu'avec Windows) mais si je comprends bien il suffit de ne pas partitionner la fin du disque (par exemple me limiter à 400 Go partitionné pour avoir un overprovisioning de 112Go supplèmentaire)
(https://lafibre.info/images/materiel/201611_ssd_samsung_4.jpg)
Avec 2 fois plus d'endurance et de fiabilité qu'un SSD à Flash NAND traditionnelle, 850 PRO continue de travailler aussi longtemps que vous le faites. La technologie V-NAND de Samsung est conçue pour gérer une charge de travail quotidienne de 40 Go, ce qui équivaut à 150 TBW (Téraoctets écrits), vous permettant ainsi d'utiliser le SSD pour de longues périodes. De plus, ce produit est garanti 10 ans.
C'est le meilleur des SSD dans ce test d'endurance : http://techreport.com/review/27909/the-ssd-endurance-experiment-theyre-all-dead
Endurance sur de gros fichiers :
(https://lafibre.info/images/materiel/201611_ssd_samsung_5.png)
Malgré quelques baisse de régimes, le Samsung 840 Pro reste supérieur à ses concurrents (crédit : TechReport)
Endurance sur des petits fichiers :
(https://lafibre.info/images/materiel/201611_ssd_samsung_6.png)
Sur les petits fichiers, le Samsung 840 Pro tient toujours la dragée haute aux autres, tandis que le Kingston HyperX 3K Comp est à la peine (crédit : TechReport).
-
Je me permet de me mêler de ce qui ne me regarde pas...
J'ai le disque dur de mon serveur (LaFibre.info) vient de me lâcher (je n'ai pas mis de RAID) après 4ans et demi de bon services. La partition /home est passé en read-only (donc plus de graphe SmokePing).
[...]
J'envisage donc de me déplacer Lundi à Maxnod pour changer le disque dur et faire comme j'avais prévu dés le départ : mettre un SSD qui me semble nettement plus fiable, vu le volume journalier écrit sur le disque.
Tu veux faire l'aller-retour + prendre un jour de congé juste pour changer un disque dur? Ca va faire cher le changement de disque dur, non?
Est-ce que tu ne peux pas déléguer ça à une personne de confiance sur place qui aurait accès au Maxnod? (Ou qu'on laisserai entrer dans Maxnod après négociation).
Ou carrèment demander à Maxnod-Adeli, même moyennant finances, ça ne reviendrait pas moins cher?
Leon.
-
Je pense que Vivien a du monde de confiance en région lyonnaise ::) et même directement chez Maxnod, si il veut se déplacer, c'est surement pour + de choses que ça ;)
(d'ailleurs vivien, tu regarderas tes DM twitter ;) )
-
En fait l’intérêt de me déplacer est de fortement limiter l'interruption de service, cr je vais arriver avec un système tout prêt avec tout d'installé / configuré. Il y aura juste la base de donnée que je sauvegarderais / transférerais au dernier moment.
C'est un serveur entrée de gamme, avec le disque dur dans le serveur.
Lors de l'installation, il y a 4 ans et demi, j'avais 3 choix possibles :
- Raid hardware en doublant le prix du serveur (les options sont hors de prix sur les serveurs Dell entrée de gamme : sur son successeur, le Poweredge R220 un disque Sata de base à 7200tr/min à 1 To est à 171€. Pour un 2 To, c'est 278€. La carte RAID : 189€. Reste la problématique de la supervision du RAID et j'ai déja vu un RAID 5 perdu à cause de deux disques tombés en panne en peu de temps.
- Raid software. J'ai toujours un peu de mal à comprendre comment l'ordinateur boot, si il perd le premier disque, celui qui as la partition /boot (à l'époque un seul disque avait cette partition dans le raid software, je ne sais pas si on a améliorer les choses depuis)
- Aucun Raid (mon choix) mais sauvegarde différentielle quotidienne. Il y a 4ans et demi, je m'étais posé la question du SSD, mais c'était encore un peu jeune à l'époque. Aujourd'hui je suis persuadé que pour des petits volume d'écriture, ils sont plus fiables, sans parler du gain en vitesse et consommation électrique.
PS : Personne n'a de serveur Online avec un SSD pour me donner la marque modèle ? (il y a de grande chance que ce soit un modèle difficilement trouvable dans le commerce, comme pour OVH / Ikoula)
-
Chez Online, c'est soit Intel soit Samsung. Concernant les SSD Samsung, j'ai vu passer la référence PM871a qui a priori semble être le clone OEM de la version 850 Pro.
-
PS : Personne n'a de serveur Online avec un SSD pour me donner la marque modèle ? (il y a de grande chance que ce soit un modèle difficilement trouvable dans le commerce, comme pour OVH / Ikoula)
Pour ma part avec ma Dedibox Limited
Device Model: SAMSUNG MZ7LN128HCHP-00000
Serial Number: S1ZFNXAG607605
LU WWN Device Id: 5 002538 d401df0e2
Firmware Version: EMT0100Q
User Capacity: 128,035,676,160 bytes [128 GB]
Sector Size: 512 bytes logical/physical
Rotation Rate: Solid State Device
Device is: Not in smartctl database [for details use: -P showall]
ATA Version is: ACS-2, ATA8-ACS T13/1699-D revision 4c
SATA Version is: SATA 3.1, 6.0 Gb/s (current: 6.0 Gb/s)
Local Time is: Fri Nov 4 15:27:28 2016 CET
SMART support is: Available - device has SMART capability.
SMART support is: Enabled
-
- Raid hardware en doublant le prix du serveur (les options sont hors de prix sur les serveurs Dell entrée de gamme : sur son successeur, le Poweredge R220 un disque Sata de base à 7200tr/min à 1 To est à 171€. Pour un 2 To, c'est 278€. La carte RAID : 189€. Reste la problématique de la supervision du RAID et j'ai déja vu un RAID 5 perdu à cause de deux disques tombés en panne en peu de temps.
Tu peux configurer un RAID1 pour limiter les risques.
La supervision se fait très simplement avec une commande par cron + un mail.
On a des dizaines de vieilles lames en RAID1 hardware et après plusieurs années je n'ai jamais eu à subir de double panne à partir du moment où c'est monitoré.
- Raid software. J'ai toujours un peu de mal à comprendre comment l'ordinateur boot, si il perd le premier disque, celui qui as la partition /boot (à l'époque un seul disque avait cette partition dans le raid software, je ne sais pas si on a améliorer les choses depuis)
Tu devais avoir une config LVM et par Linux RAID SW (MD driver).
Dans ce cas il faut maintenir deux partitions /boot (une sur chaque disque), ensuite après chargement du Ramfs le LVM va s'activer de manière transparente sur le disque restant.
Autre solution : passer /boot sur un device RAID SW (/dev/mdxx) : Linux supporte le boot sur un device MD (regénération initramfs avec inclusion du driver MD).
https://access.redhat.com/solutions/1360363 (https://access.redhat.com/solutions/1360363)
-
En fait l’intérêt de me déplacer est de fortement limiter l'interruption de service, cr je vais arriver avec un système tout prêt avec tout d'installé / configuré. Il y aura juste la base de donnée que je sauvegarderais / transférerais au dernier moment.
OK, je comprends que ton choix est déjà fait. Et si tu as d'autres choses intéressantes à faire sur la région de Lyon, c'est tant mieux!
Mais n'aurais-tu pas pu faire la même chose en restant en région parisienne?
Donc préparer ton SSD chez toi et l'envoyer par Chronopost au Maxnod ou à une personne de confiance sur place? Et au dernier moment, travailler depuis Paris, main dans la main avec un "remote hands" (personne de confiance qui s'y connait) à distance pour faire le transfert final de la base de données?
Ou alors préparer une "image" de l'installation du SSD chez toi, la faire installer par une personne de confiance sur un disque dur acheté sur place à Lyon, avant d'intervenir sur le serveur?
Sinon, elle fait quelle taille la base de donnée du forum? Quelques Go? Dizaines de Go?
Bon courage pour la migration!
Leon.
-
J’aurais su dés le départ que le disque allait compétemment me lâcher, avec migration sur un serveur temporaire, je ne me serais probablement pas déplacé.
Maintenant, j'ai prévu de rendre visite a ma grand-mère dimanche soir, tout est organisé et j'ai aussi des besoin pas prioritaires comme mettre à jour le bios et reconfigurer DRAC (le KVM pour un accès à distance en cas de pb).
La base de donnée MySQL est petite : 420 Mo, il y a par contre plusieurs dizaines de Go de fichiers (pièces jointes, images,...)
-
La base de donnée MySQL est petite : 420 Mo, il y a par contre plusieurs dizaines de Go de fichiers (pièces jointes, images,...)
Moins de 500Mo, ça doit rentrer facilement en totalité en cache en RAM, non? Du coup, si c'est bien le cas, pour ce qui est des accès à la base de données, les performances du disque dur (rapidité de lecture ou d'écriture) n'entrent sans doute pas du tout en compte (ou très peu).
Pour l'accès aux images et aux pièces jointes, là, d'accord, il faut de bonnes perfo du disque dur en lecture. Mais c'est sans doute moins critique.
Après, il faut clairement un disque très endurant vu le nombre d'écritures.
Leon.
-
Le choix du SSD n'est pas réalisé pour des raisons de performance, mais d’endurance.
Les disques dur classiques ont une durée de vie toujours limitée (4ans et demi, c'est pas si mal que ça), j’espère faire bien mieux avec un SSD. Peut-être que je me trompe, mais le seul moyen d’apprendre, c'est de tester.
Pour la base SQL, j'ai configuré un gros cache (pas trop, sinon on perd du temps pour chercher l'info) et sinon la base dois être en cache disque au niveau du système de fichier après la première lecture.
-
Le choix du SSD n'est pas réalisé pour des raisons de performance, mais d’endurance.
Une étude de Google sur leurs millions de DD pendant 6 ans montre :
- SSD plus fiables que HDD mais plus prones a perdre des données.
- l'age affecte plus les SSD que leur taux d'utilisation.
- les SLC haut de gamme ne sont pas plus fiables que les MLC bas de gamme ... (ouch!)
l'etude: https://www.usenix.org/system/files/conference/fast16/fast16-papers-schroeder.pdf
-
Pour la base SQL, j'ai configuré un gros cache (pas trop, sinon on perd du temps pour chercher l'info) et sinon la base dois être en cache disque au niveau du système de fichier après la première lecture.
Oula, ne compte pas sur le cache du filesystem qui dévalide à la moindre modif.
Avoir des tables en InnoDB avec un pool size d'un 1Go c'est parfait, là ton MySQL saura gérer ça comme il faut :)
-
Oula, ne compte pas sur le cache du filesystem qui dévalide à la moindre modif.
Lors d'une modif le filesystem Ext4 écrit la modif sur le disque et garde la modif en cache.
Les lectures ultérieures se feront depuis la RAM
Je ne comprends pas bien ce que tu dis (et je vois dans mes stats IO disque, qu'il n'y a presque aucun accès en lecture sur le disque après avoir tourné plusieurs jours)
Il y a par contre toujours les écritures.
-
Quand tu écris ta modification : les données précédemment en cache sont invalidées, les nouvelles sont écrites sur disque et conservées en cache.
-
Quand tu écris ta modification : les données précédemment en cache sont invalidées, les nouvelles sont écrites sur disque et conservées en cache.
Du coup, je ne vois pas où est le problème décrit par Optix...
Leon.
-
Si le problème c'est l'overprovisionning, tu peux le faire manuellement en ne partitionnant pas la totalité. Je te renvoie à cet article (http://www.hardware.fr/articles/906-16/tenue-performances.html) pour plus de détails sur la tenue des performances en fonction de ce que tu décide de provisionner.
Le menu Over provisioning de l'applicaiton Samung, ne fait en effet que réduire la partition pour laisser 10% d'espace non provisionné.
Extrait de la doc :
La fonction Over provisioning permet de redimensionner les partitions d’un lecteur. Les SSD fonctionnement mieux et durent plus longtemps lorsqu’ils disposent d’une grande quantité d’espace utilisable comme espace d’échange.
Durant les périodes d’inactivité, l’espace d’échange est utilisé pour effectuer en arrière-plan les tâches de maintenance courante du SSD (fonctions TRIM et Garbage Collection), ce qui permet au contrôleur SSD de préparer des blocs libres en vue d’une utilisation ultérieure. Dans la mesure où le SSD offre de meilleures performances lorsqu’il écrit dans des blocs libres, il en résulte une meilleure expérience utilisateur.
La fonction Over provisioning contribue à dégager de l’espace libre en redimensionnant les partitions d’un lecteur.
Les explications pour la taille du disque annoncée vs réelle :
Remarque : LES SAMSUNG SSD SONT CONFORMES À LA NORME IDEMA (INTERNATIONAL DISK DRIVE EQUIPMENT AND MATERIALS), QUI CLASSIFIE ENVIRON 93 % DE LEUR MÉMOIRE PHYSIQUE EFFECTIVE EN TANT QU’ESPACE UTILISABLE POUR LE STOCKAGE. AFIN DE SIMPLIFIER LES CALCULS POUR LES CONSOMMATEURS, LE FABRICANT ÉVALUE LA CAPACITÉ DES LECTEURS EN CONSIDÉRANT QUE 1 GO EST ÉGAL À 1 000 MÉGAOCTETS (MO)
(https://lafibre.info/images/materiel/201611_ssd_samsung_7.png)
Descriptions de certains attributs SMART des SSD Samsung :
- Reallocated Sector Count : Nombre de secteurs ayant été réalloués. Quand le disque dur obtient une erreur de lecture/écriture/vérification sur un secteur, il note ce secteur comme réalloué et transfère les données vers un nouveau secteur situé dans une zone réservée spéciale.
- Power-On Hours : Nombre d’heures pendant lequel le lecteur a été en fonctionnement. Cette valeur est un simple indicateur du comportement de l’utilisateur, et n’est pas directement liée à l’état de fonctionnement du lecteur. La valeur brute de cet attribut indique le nombre total d’heures (ou, selon le constructeur, de minutes ou de secondes) de fonctionnement du disque. Lorsque l’ordinateur est en mode de veille prolongée, la valeur Power-On Hours n'augmente pas.
- Power-on Count : Nombre de cycles de mise sous/hors tension complets du disque.
- Wear Leveling Count : Représente le nombre d’opérations d’effacement effectuées sur le support (le nombre de fois qu’un bloc a été effacé).
- Used Reserved Block Count : Représente le nombre total de blocs réservés ayant été utilisés suite à un échec d’une demande programme ou d’une demande d’effacement.
- Program Fail Count : Nombre de demandes programme (d’écriture) ayant échoué.
- Erase Fail Count : Nombre de demandes d’effacement ayant échoué.
- Runtime Bad Count : Correspond à la somme de Program Fail Count et de Erase Fail Count. Cette valeur récapitulative représente le nombre total cumulé d’échecs de demandes programme et de demandes d’effacement.
- Uncorrectable Error Count : Nombre total d’erreurs n’ayant pas pu être corrigées via ECC.
- Air Flow Temperature : Température actuelle des puces NAND situées à l’intérieur du SSD.
- ECC Error Rate : Nombre d’erreurs corrigibles. Nombre d’erreurs corrigées par le mécanisme interne de correction d’erreurs.
- CRC Error Count : The number of Cyclic Redundancy Check (CRC) errors. If there is a problem between the host and the DRAM or NAND flash, the CRC engine will tally the error and store it in this attribute.
- POR Recovery Count : Nombre de cas de mise hors tension soudaine. En cas de mise hors tension soudaine, le microcode doit récupérer l’ensemble des données de mappage et des données utilisateur lors de la prochaine mise sous tension. Cet attribut comptabilise le nombre de fois où cette séquence s’est produite.
- Total LBAs Written (attribut SMART 241) : Représente la taille totale des blocs LBA (Logical Block Addressing) requis pour traiter l’ensemble des demandes d’écriture envoyées au SSD depuis l’hôte. Pour calculer la taille totale (en octets), il faut multiplier la valeur remontée par SMART par 512.
RAW_VALUE = 212601749
Taille écrite = 108852095488 octets = 108,8 Go
To est l'abréviation de « téraoctet », soit 1 000 Go.
Les détails ci-après sont renseignés pour chaque attribut SMART :
- ID : Nom décimal de l’attribut SMART.
- Description : Nom de l’attribut SMART.
- Seuil : Seuil à partir duquel la valeur normalisée est considérée comme « dépassant les spécifications ».
- Valeur actuelle : Valeur normalisée actuelle de l’attribut.
- Pire valeur : Valeur la plus médiocre signalée relativement au lecteur sélectionné pour un attribut donné.
- Données brutes : Valeur brute affectée à l’attribut SMART par le fabricant du lecteur.
- Status : Indique si le système peut ou non effectuer un traitement sur le lecteur.
SMART Attributes Data Structure revision number: 1
Vendor Specific SMART Attributes with Thresholds:
ID# ATTRIBUTE_NAME FLAG VALUE WORST THRESH TYPE UPDATED WHEN_FAILED RAW_VALUE
5 Reallocated_Sector_Ct 0x0033 100 100 010 Pre-fail Always - 0
9 Power_On_Hours 0x0032 099 099 000 Old_age Always - 217
12 Power_Cycle_Count 0x0032 099 099 000 Old_age Always - 4
177 Wear_Leveling_Count 0x0013 100 100 000 Pre-fail Always - 0
179 Used_Rsvd_Blk_Cnt_Tot 0x0013 100 100 010 Pre-fail Always - 0
181 Program_Fail_Cnt_Total 0x0032 100 100 010 Old_age Always - 0
182 Erase_Fail_Count_Total 0x0032 100 100 010 Old_age Always - 0
183 Runtime_Bad_Block 0x0013 100 100 010 Pre-fail Always - 0
187 Reported_Uncorrect 0x0032 100 100 000 Old_age Always - 0
190 Airflow_Temperature_Cel 0x0032 073 072 000 Old_age Always - 27
195 Hardware_ECC_Recovered 0x001a 200 200 000 Old_age Always - 0
199 UDMA_CRC_Error_Count 0x003e 100 100 000 Old_age Always - 0
235 Unknown_Attribute 0x0012 100 100 000 Old_age Always - 0
241 Total_LBAs_Written 0x0032 099 099 000 Old_age Always - 212601749
-
Du coup, je ne vois pas où est le problème décrit par Optix...
Leon.
J'ai tendance à me méfier du cache, car d'expérience j'ai eu des soucis de perfs après que je subissais de grosses écritures. Quand un user écrivait son gros contenu, son logiciel relisait aussitôt derrière pour voir si l'opération s'est bien déroulée et que j'ai encaissé tous les fichiers. Bah les lectures, je les ai senti passer :(
Du coup je préfère allouer beaucoup de mémoire aux applications qui savent comment gérer ça à leur sauce, plutôt qu'au filesystem qui essaye de faire au mieux pour tous les usages. MySQL gérera mieux la RAM pour son usage que n'importe quel FS.
Compte tenu du message de vivien, que ext4 commit les modifs également dans le cache, je pense que mon souci devait venir du fait que je n'utilise que des FS réseaux. Pas facile de mettre à jour le cache sur les X machines qui ont le FS monté :)
-
Le problème d'Optix était donc plutôt un problème de taille du cache : beaucoup d'I/O avec plusieurs applications. La gestion du cache est compliquée.
Le cas de Vivien est plus simple: une seule application et peu d'I/O. La gestion du cache est facile.
-
Le filesystem n'as pas forcèment la même taille de blocs que la BDD, ni les mêmes règles et cycles de renouvellement (LRU).
De plus sur certains SGBD il est possible de forcer la conservation des tables entières en cache BDD, pour privilégier certaines requêtes, ce dont le cache filesystem n'aura aucune connaissance .
Enfin le cache filesystem subira des évictions pénalisantes en cas de forte demande de mémoire applicative (heap), alors que la plupart des SGBD sérieux lockent en RAM leur cache.
Donc, il est préférable de mettre la cache là où le mécanisme est le plus compétent pour le gérer, c'est à dire dans le SGBD.
-
Hello,
Nous utilisons principalement des SSD Samsung série MZ7LN256HMJP (PM871a). C'est un dérivé en TLC des EVO avec un peu plus d'overprovisionning.
Ils ne sont pas disponibles sur le marché "normal", ce sont des références spécifiques disponibles uniquement en direct constructeur.
Nous avons essayé d'autres marques (notamment Intel et Micron) et n'avons jamais réussi à avoir une endurance convenable, pour un rapport fiabilité/performance/prix nettement inférieur.
Nous en avons déployé plusieurs dizaines de milliers depuis 18 mois, nous avons un taux de casse inférieur à 0,2% (une trentaine à peu près)
Arnaud