Problem z dyskiem (?) WD RE4, wolne transfery

[t4t4v4 3]

Witajcie,

Mam problem z dyskiem. Gdy wyłączę Apacza, odczyt jest na poziomie 100-120 MB/s. Po włączeniu Apacza odczyt spada do 8 MB/s - iotop nie pokazuje poważnego zużycia IO przez procesy serwera WWW, maksymalnie kilka procent.

Poniżej wklejam SMART'a dysku:

=== START OF INFORMATION SECTION ===
Device Model:     WDC WD5003ABYX-01WERA1
Serial Number:    WD-WMAYP6057496
Firmware Version: 01.01S02
User Capacity:    500,107,862,016 bytes
Device is:        Not in smartctl database [for details use: -P showall]
ATA Version is:   8
ATA Standard is:  Exact ATA specification draft version not indicated
Local Time is:    Sat Sep 13 21:06:36 2014 CEST
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:      (   0) The previous self-test routine completed
                                        without error or no self-test has ever
                                        been run.
Total time to complete Offline
data collection:                 (8160) 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:        (  83) 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       -       1
  3 Spin_Up_Time            0x0027   140   140   021    Pre-fail  Always       -       3966
  4 Start_Stop_Count        0x0032   100   100   000    Old_age   Always       -       21
  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   091   090   000    Old_age   Always       -       6936
 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       -       18
192 Power-Off_Retract_Count 0x0032   200   200   000    Old_age   Always       -       10
193 Load_Cycle_Count        0x0032   200   200   000    Old_age   Always       -       10
194 Temperature_Celsius     0x0022   110   101   000    Old_age   Always       -       33
196 Reallocated_Event_Count 0x0032   200   200   000    Old_age   Always       -       0
197 Current_Pending_Sector  0x0032   200   200   000    Old_age   Always       -       0
198 Offline_Uncorrectable   0x0030   200   200   000    Old_age   Offline      -       0
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      -       0

Mieliście kiedyś podobny problem? Moglibyście podać jakiś trop?

[www.ionic.pl 535]

vmstat ?

[t4t4v4 3]

Jak już sprawdziłem, wolny transfer powoduje zarządca deadline (pytanie dlaczego? ). Poniżej wyniki hdparm i vmstat na CFQ i deadline (na sda jest kopia zapasowa i MySQL, na sdb wszystkie pliki Apache):

# hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads: 350 MB in  3.00 seconds = 116.65 MB/sec

# hdparm -t /dev/sdb
/dev/sdb:
 Timing buffered disk reads: 138 MB in  3.04 seconds =  45.39 MB/sec

# vmstat 5 30
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 0  0  71652 1247808 288516 1514312    0    0    38    25   16    0  8  2 67 22
 0  2  71652 1222572 289680 1518948    0    0  1113   628 1012 1007  5  2 83 10
 1  0  71652 1211692 290684 1525428    0    0  1471   377 1182 1078 11  2 77 11
 2  0  71652 1172720 291012 1526572    0    0   337   314 1462 1032 29  4 64  3
 1  1  71652 1210448 292796 1533244    6    0  1652   645 1749 2689 25  5 51 20
 1  0  71652 1188336 293700 1539276    6    0  1160   690 1758 1993 21  5 62 12
 1  0  71652 1184660 294284 1544016    0    0   844   842 1605 1652 14  3 77  5
 1  7  71652 1168600 296108 1551344    0    0  1786   163 1473 1663 14  3 50 33
 2  9  71652 1107116 297484 1559688    6    0  1857   164 1684 1524 12  3  9 76
 0  6  71648 1027676 298872 1574656    0    0  3238   219 2088 1911 15  4 14 67
 0 20  71648 989344 300184 1581808    0    0  1729   186 1922 1503  8  3 12 76
 1 19  71648 929340 301192 1592296    0    0  2285   202 1755 1494 12  3 10 75
 1 14  71648 1014400 302204 1599804    0    0  1652   203 1647 1267 13  3 13 71
 0 16  71648 1015252 303288 1604796    0    0  1221   521 2773 2136 12  4 27 57
 1  2  71648 1008812 304536 1612132    0    0  1506   849 1419 1432 11  2 40 46
 1  0  71648 1068688 305440 1615056    6    0   801   675 1651 2398 19  6 64 11
 1  0  71648 1065636 308188 1618600    0    0  1253   334 1988 2647 20  8 54 18
 1  0  71648 1027176 309192 1624432    0    0  1319   304 1807 2677 23  8 61  9
 1  1  71648 1052896 309592 1625372    0    0   270   174 1721 2467 22  7 66  5
 0  4  71648 1052504 310088 1629704    0    0   970   554 1304 1768 11  5 67 17
 0  0  71648 1069036 310816 1632816    0    0   736   263 1230 1860 10  5 44 41
 1  0  71648 1073520 310936 1633332    0    0   119   181  831 1039  4  3 92  1
 0  1  71648 1066436 311348 1635568    0    0   534   277 1325 1636  6  5 82  7
 1  0  71648 1068660 312820 1643508    0    0  1895   139 2083 2243 13  6 63 18
 0  0  71648 1072236 313428 1647712    0    0   918   342 2010 1616  5  4 85  7
 1  0  71648 1049940 313792 1652388    0    0   846   372  863  879  5  1 90  4
 0  0  71648 1077912 313944 1652492    0    0    55   483  739  906  5  1 92  2
 0  0  71648 1083332 314024 1653176    0    0   127   102  654  559  4  2 94  1
 1  0  71648 1051828 314376 1657448    0    0   925   393 1859 1013  8  3 83  6
 0  0  71648 1071608 314712 1660724    0    0   686   226 1449 1190 10  3 82  5

# echo deadline > /sys/block/sda/queue/scheduler
# echo deadline > /sys/block/sdb/queue/scheduler

# hdparm -t /dev/sda
/dev/sda:
 Timing buffered disk reads: 360 MB in  3.01 seconds = 119.42 MB/sec

# hdparm -t /dev/sdb
/dev/sdb:
 Timing buffered disk reads:  16 MB in  4.38 seconds =   3.65 MB/sec

# vmstat 5 30
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
 1  1  71632 1555596 302936 1191184    0    0    39    25   17    1  8  2 67 22
 0  0  71632 1563464 303512 1191748    0    0   216   166  938  890  6  1 89  3
 0  1  71632 1510004 305304 1197136    0    0  1410   345 1350  945  4  2 81 12
 0  1  71632 1515336 307696 1205928    0    0  1965   444 1261 1011  6  2 75 18
 0  5  71632 1528364 308160 1206988    0    0   251  1283  917  683  4  1 88  8
 1  2  71632 1500244 309544 1210976    0    0  1042   734 1699 1312 14  2 53 31
 0  0  71632 1528812 310596 1218732    0    0  1724   294 1298  831  4  2 76 17
 0  0  71632 1514112 310868 1220868    0    0   469   145  867  460  2  1 94  3
 0  2  71632 1459668 311800 1230680    0    0  2114   294 1646 1144  9  3 70 19
 0  0  71632 1519128 312100 1233032    0    0   487   205  981  483  3  1 91  5
 1  0  71632 1469792 312704 1238920    0    0  1300   158 1222  895  7  2 81 10
 1  0  71632 1446976 313240 1242500    0    0   798   202  859  649  5  1 90  3
 0  0  71632 1507196 313632 1247852    0    0  1128   542 1196  873  6  1 77 16
 0  1  71632 1459712 314556 1257128    0    0  2022   367 1260 1002  5  2 84 10
 0  0  71632 1466532 314972 1257260    0    0    98   125  774  600  4  1 92  3
 0  1  71632 1490116 315868 1262472    0    0  1200   729 1128 1022  6  2 81 11
 0  0  71632 1484100 317160 1264972    0    0   740   155 1308 1225  7  3 75 16
 0  0  71632 1485396 317420 1266500    0    0   327   554  625  364  3  1 94  3
 0  0  71632 1486752 317592 1266628    0    0    49    97  555  507  2  1 97  1
 0  3  71632 1421632 318632 1275116    0    0  1778   755 1594 1011  8  2 63 27
 0  3  71632 1446464 319844 1280036    0    0  1175   373 1478  869  4  1 68 27
 1  2  71632 1439560 321176 1284020    0    0  1059   193 1226  711  3  2 71 24
 0  5  71632 1401212 322336 1289036    0    0  1056   154 1300 1014  9  2 56 33
 0  6  71632 1364120 323716 1295588    0    0  1443   458 1437 1416  9  2 53 36
 0  2  71632 1388368 324852 1300380    0    0  1169   532 2193 1677  8  3 31 58
 0  0  71632 1426632 325172 1305200    0    0   984   322 1713  910  3  1 87  8
 1  0  71632 1397904 325308 1306056    0    0   178   586  976  631  4  1 88  7
 0  0  71632 1432548 325508 1308212    0    0   494   167 1136  571  9  2 86  3
 0  0  71632 1419752 326112 1317884    0    0  2005   182 1674  905  8  2 85  5
 0  0  71632 1418520 326488 1319464    0    0   376   155 1194  792  7  2 87  3

Czy te dyski nie są w stanie pracować z zarządcą deadline?

[Pan Kot 1535]

Nie ma czegoś takiego jak "nie są w stanie". Upewnij się, że nie masz antycznego kernela (poprawki do deadline'a co jakiś czas wpadają). Poza tym z natury działania deadline nie zaoferuje Ci najlepszej szybkości dla X requestów, to właśnie robi CFQ. Deadline minimalizuje overhead poprzez nieco szybsze serwowanie requestów, tyle że idąc deadlinem, czyli jeśli te benchmarki robisz na jakkolwiek obciążonej maszynie to requesty MySQL czy czegokolwiek co tam masz będą na pierwszym miejscu, a benchmark dopiero na ostatnim. Normalne zachowanie tego governora. Jeśli liczby bardziej do ciebie przemawiają niż fakt, że w rzeczywistości deadline jest szybszy to zostań przy CFQ bo tylko on gwarantuje równomierne rozłożenie I/O.

Edytowano Wrzesień 20, 2014 przez Archi (zobacz historię edycji)

[t4t4v4 3]

Dzięki za odpowiedź.
Kernel jest w wersji 3.16.2.Właśnie problem występuje tylko z dyskiem, z którego serwowane są stronki na Apache (jakieś 20 requestów na sekundę) - stąd może wynikać zaniżony wynik benchmarku? Dodam, że po wyłączeniu Apache'a, benchmark śmiga aż miło.

Warto zostawić deadline?

[Pan Kot 1535]

To zależy.

 

Deadline polecam używać, jeśli I/O na ogół się nudzi i co jakiś czas dostaje requesty, wtedy będzie to szybsze.

 

Jeśli I/O jest cały czas "in use", czyli większość scenariuszy, CFQ prawdopodobnie sprawdzi się tutaj lepiej. Chyba, że kontrolujesz co się dzieje i nie martwisz się o równomierny dostęp do I/O tylko o jak najszybsze zakończenie requesta, wtedy deadline wciąż wygrywa.

 

Jeśli ten apache nie powoduje obciążenia to zaniżony wynik benchmarka jest co najmniej dziwny, deadline będzie miał "mniejsze liczby" pod obciążeniem, ale jeśli tego obciążenia nie ma to powinien być minimalnie szybszy w liczbach od CFQ, tak jak to pokazuje benchmark pierwszego dysku.

Edytowano Wrzesień 20, 2014 przez Archi (zobacz historię edycji)

[t4t4v4 3]

Benchmark deadline bez obciążenia jest szybszy od benchmarku na CFQ - wystarczy wyłączyć Apache i widać różnicę.

Deadline spodobał mi się, bo spadł mi load maszyny i IOWait procesora..
Jednak znacząco wydłużył się czas robienia backup'u (rsync części danych z sdb na sda). Backup na CFQ wykonuje się krócej, ale load potrafi pójść w kosmos - przy deadline robił się trochę dłużej, ale load nie przekraczał kilku jednostek.

Będę eksperymentować, jeszcze raz dzięki