Автор Тема: Впервые в Simply Linux: от чего замирает система и как ее лучше обновлять?  (Прочитано 26694 раз)

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
Добавление. После выполнения:
# hdparm -B 254 /dev/sdaдиск ну просто явно стал поминутно засыпать/просыпаться ...

Поэтому вернула обратно:
hdparm -S 254 /dev/sda- так намного лучше.
Наблюдаю дальше :)

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
А это замирание кроме высокой загрузки процессора сопровождалось какой-либо "озвучкой" со стороны HDD?
Посмотрю еще ...

Поэтому для исключения постороннего влияния при наблюдении, возможно, имеет смысл контролировать текущие значения (для -S такой возможности нет):
# hdparm -B -M -W /dev/sda
Вот что показывает:
[root@linux ~]# hdparm -B -M -W /dev/sda

/dev/sda:
 write-caching =  0 (off)
 APM_level = 1
 acoustic      = not supported
И что это значит? :)

pps. Сводку о возможностях HDD можно посмотреть
hdparm -I /dev/sdaзаодно проверьте, что диск не в PIO режиме (чтоб уж точно быть уверенным, что проблема не в этом).
Посмотрела:
[root@linux ~]# hdparm -I /dev/sda

/dev/sda:

ATA device, with non-removable media
Model Number:       Hitachi HUA722050CLA330                 
Serial Number:      JPW9K0J81TKX1L
Firmware Revision:  JP2OA3EA
Transport:          Serial, ATA8-AST, SATA 1.0a, SATA II Extensions, SATA Rev 2.5, SATA Rev 2.6; Revision: ATA8-AST T13 Project D1697 Revision 0b
Standards:
Used: unknown (minor revision code 0x0029)
Supported: 8 7 6 5
Likely used: 8
Configuration:
Logical max current
cylinders 16383 16383
heads 16 16
sectors/track 63 63
--
CHS current addressable sectors:   16514064
LBA    user addressable sectors:  268435455
LBA48  user addressable sectors:  976773168
Logical/Physical Sector size:           512 bytes
device size with M = 1024*1024:      476940 MBytes
device size with M = 1000*1000:      500107 MBytes (500 GB)
cache/buffer size  = 29999 KBytes (type=DualPortCache)
Form Factor: 3.5 inch
Nominal Media Rotation Rate: 7200
Capabilities:
LBA, IORDY(can be disabled)
Queue depth: 32
Standby timer values: spec'd by Standard, no device specific minimum
R/W multiple sector transfer: Max = 16 Current = 16
Advanced power management level: 1
DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
     Cycle time: min=120ns recommended=120ns
PIO: pio0 pio1 pio2 pio3 pio4
     Cycle time: no flow control=120ns  IORDY flow control=120ns
Commands/features:
Enabled Supported:
   * SMART feature set
    Security Mode feature set
   * Power Management feature set
    Write cache
   * Look-ahead
   * Host Protected Area feature set
   * WRITE_BUFFER command
   * READ_BUFFER command
   * DOWNLOAD_MICROCODE
   * Advanced Power Management feature set
    Power-Up In Standby feature set
   * SET_FEATURES required to spinup after power up
    SET_MAX security extension
   * 48-bit Address feature set
   * Device Configuration Overlay feature set
   * Mandatory FLUSH_CACHE
   * FLUSH_CACHE_EXT
   * SMART error logging
   * SMART self-test
    Media Card Pass-Through
   * General Purpose Logging feature set
   * WRITE_{DMA|MULTIPLE}_FUA_EXT
   * 64-bit World wide name
   * URG for READ_STREAM[_DMA]_EXT
   * URG for WRITE_STREAM[_DMA]_EXT
   * WRITE_UNCORRECTABLE_EXT command
   * Segmented DOWNLOAD_MICROCODE
   * Gen1 signaling speed (1.5Gb/s)
   * Gen2 signaling speed (3.0Gb/s)
   * Native Command Queueing (NCQ)
   * Host-initiated interface power management
   * Phy event counters
   * NCQ priority information
    Non-Zero buffer offsets in DMA Setup FIS
    DMA Setup Auto-Activate optimization
   * Device-initiated interface power management
    In-order data delivery
   * Software settings preservation
   * SMART Command Transport (SCT) feature set
   * SCT LBA Segment Access (AC2)
   * SCT Error Recovery Control (AC3)
   * SCT Features Control (AC4)
   * SCT Data Tables (AC5)
Security:
Master password revision code = 65534
supported
not enabled
not locked
not frozen
not expired: security count
not supported: enhanced erase
112min for SECURITY ERASE UNIT.
Logical Unit WWN Device Identifier: 5000cca396d9439f
NAA : 5
IEEE OUI : 000cca
Unique ID : 396d9439f
Checksum: correct
Но ничего не поняла  ???

И еще: как можно проверить в Линуксе, что диск не в PIO режиме?

Оффлайн ksa

  • Модератор глобальный
  • *****
  • Сообщений: 9 049
Цитировать
...
Capabilities:
   LBA, IORDY(can be disabled)
   Queue depth: 32
   Standby timer values: spec'd by Standard, no device specific minimum
   R/W multiple sector transfer: Max = 16   Current = 16
   Advanced power management level: 1
   DMA: mdma0 mdma1 mdma2 udma0 udma1 udma2 udma3 udma4 udma5 *udma6
        Cycle time: min=120ns recommended=120ns
   PIO: pio0 pio1 pio2 pio3 pio4
        Cycle time: no flow control=120ns  IORDY flow control=120ns
...
Собственно, где звездочка стоит, этот режим работы и выбран. В вашем случае этот режим udma6, что никак не pio :)

Оффлайн bormant

  • Участник
  • *
  • Сообщений: 358
В разделе "Capabilities" текущий режим отмечен звёздочкой -- "*udma6", так что с этой стороны проблемы нет.

"acoustic      = not supported" -- с ключом -M нет смысла обращаться к HDD, он не поддерживает эту возможность.

"APM_level   = 1" -- а вот тут не совсем понятно, 1 -- это наиболее энергосберегающий режим (и главный кандидат на источник проблемы). Правильно ли понимаю, что это значение получится и после выполнения:
# hdparm -B 254 /dev/hda
# hdparm -B /dev/hda
или только если между командами был достаточно продолжительный интервал (и кто-то успел поменять параметры энергосбережения)? Во втором случае нужно будет искать этого "кто-то".

"write-caching =  0 (off)" -- отключен кэш при записи на диск. Включение (-W) позволяет снизить время отклика по записи, но цена может быть неприемлемо высока -- случайное отключение питания при несброшенном кэше может стать источником значительных проблем с целостностью данных и самих файловых систем на устройстве.

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
Собственно, где звездочка стоит, этот режим работы и выбран. В вашем случае этот режим udma6, что никак не pio :)
Ну и слава Богу!
Я прочитала, что pio это нечто устаревшее, а у меня диск совершенно новый :)

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241

"APM_level   = 1" -- а вот тут не совсем понятно, 1 -- это наиболее энергосберегающий режим (и главный кандидат на источник проблемы). Правильно ли понимаю, что это значение получится и после выполнения:
# hdparm -B 254 /dev/hda
# hdparm -B /dev/hda

Нет, все по-другому:
[root@linux ~]# hdparm -B 254 /dev/sda

/dev/sda:
 setting Advanced Power Management level to 0xfe (254)
 APM_level = off

[root@linux ~]# hdparm -B /dev/sda

/dev/sda:
 APM_level = off
Очень странно ...
А при переходе в ждущий/спящий режим, значения  APM_level не могут изменится?
Я же пока ничего никуда не прописывала,просто наблюдаю ...

Цитировать
"write-caching =  0 (off)" -- отключен кэш при записи на диск. Включение (-W) позволяет снизить время отклика по записи, но цена может быть неприемлемо высока -- случайное отключение питания при несброшенном кэше может стать источником значительных проблем с целостностью данных и самих файловых систем на устройстве.
Не будем :)

Оффлайн bormant

  • Участник
  • *
  • Сообщений: 358
Написанное в ответе №50 как раз вполне ожидаемо -- что установили, то и прочитали.
А вот когда и кто туда APM_level=1 прописывает -- это уже очень интересный вопрос.

При выходе из ждущего/спящего режима параметры могу меняться, один из подозреваемых -- pm-utils.

Кроме того, нет ли чего интересного в log-ах (dmesg, /var/log/messages)?

К сожалению, эксперименты в этой части у меня на VirtualBox не пройдут, виртуальный диск говорит, что не поддерживает APM_level.
« Последнее редактирование: 07.12.2011 20:59:56 от bormant »

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
Написанное в ответе №50 как раз вполне ожидаемо -- что установили, то и прочитали.
А вот когда и кто туда APM_level=1 прописывает -- это уже очень интересный вопрос.

При выходе из ждущего/спящего режима параметры могу меняться, один из подозреваемых -- pm-utils.
Ну вот, вроде стало проясняться.
Сегодня утром после включения:

[root@linux ~]# hdparm -B -W /dev/sda
/dev/sda:
 write-caching =  1
 APM_level = off

После возвращения из ждущего режима:
[root@linux ~]# hdparm -B -W /dev/sda
/dev/sda:
 write-caching =  0 (off)
 APM_level = 1

Может это правда утилита pm-utils?
Цитировать
основной скрипт (pm-action, вызываемый через символическую ссылку как pm-suspend или pm-hibernate) выполняет так называемые “hooks”, скрипты, расположенные в /etc/pm/hooks в алфавитном порядке, с параметрами suspend (suspend to RAM) или hibernate (suspend to disk). Как только все “hooks” сделаны, компьютер отправляется в “сон”. После того, как машина снова пробудилась, все “крюки” выполняются в обратном порядке с параметром resume (resume from RAM) или thaw (resume from disk). “Крюки” делают различные вещи, например, готовят bootloader, останавливают подсистему bluetooth или выгружают критические модули.

Хм, а если прописать команду в /etc/rc.d/rc.local, как вы предлагали здесь: http://forum.altlinux.org/index.php/topic,13589.msg159067.html#msg159067
это исправит ситуацию?

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
Кроме того, нет ли чего интересного в log-ах (dmesg, /var/log/messages)?

Лог dmesg весь не влезает в сообщение вот его концовка:
[root@linux ~]# dmesg
...
[   11.424188] kjournald starting.  Commit interval 5 seconds
[   11.424575] EXT3-fs (sda8): using internal journal
[   11.424580] EXT3-fs (sda8): mounted filesystem with writeback data mode
[   11.521326] fuse init (API version 7.16)
[   15.544748] Bluetooth: Core ver 2.16
[   15.544772] NET: Registered protocol family 31
[   15.544773] Bluetooth: HCI device and connection manager initialized
[   15.544775] Bluetooth: HCI socket layer initialized
[   15.544777] Bluetooth: L2CAP socket layer initialized
[   15.545305] Bluetooth: SCO socket layer initialized
[   15.659532] Bluetooth: BNEP (Ethernet Emulation) ver 1.3
[   15.659534] Bluetooth: BNEP filters: protocol multicast
[   16.092893] sky2 0000:02:00.0: eth0: enabling interface
[   17.547338] [drm] force priority to high
[   17.794623] sky2 0000:02:00.0: eth0: Link is up at 100 Mbps, full duplex, flow control both
[   17.859413] [drm] force priority to high
[   18.000052] NET: Registered protocol family 17
[   26.693330] hda-intel: IRQ timing workaround is activated for card #1. Suggest a bigger bdl_pos_adj.
[   26.812310] ata1.00: configured for UDMA/133
[   26.812319] ata1: EH complete
[   36.847387] EXT4-fs (sda6): re-mounted. Opts: commit=0
Может быть, что и есть интересное в этих логах, но мне это неизвестно. :)
Да, этот лог был сделан сразу после включения, когда:
write-caching =  1
APM_level   = off

И еще вот что:
[root@linux ~]# /var/log/messages
-bash: /var/log/messages: Отказано в доступе

К сожалению, эксперименты в этой части у меня на VirtualBox не пройдут, виртуальный диск говорит, что не поддерживает APM_level.
Про VirtualBox пока еще ничего не знаю :)
« Последнее редактирование: 08.12.2011 14:35:45 от Баяна »

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
Написанное в ответе №50 как раз вполне ожидаемо -- что установили, то и прочитали.
А вот когда и кто туда APM_level=1 прописывает -- это уже очень интересный вопрос.

Ну вот, после возвращения из Спящего режима наблюдаем такую картину:
[root@linux ~]# hdparm -B -W /dev/sda
/dev/sda:
 write-caching =  0 (off)
 APM_level = 1

Теперь точно ясно, что "кто-то" - те программы, которые управляют Ждущим и Спящим режимом.
Как с ними договориться? :)

Оффлайн Баяна

  • Участник
  • *
  • Сообщений: 241
Понаблюдайте за эффектом. Если помогло -- прописать команду в /etc/rc.d/rc.local#!/bin/bash
hdparm -S 254 /dev/sda
Да, похоже торможение действительно возникало из-за режима энергосбережения HDD.
При APM_level   = off, ничего не замирает и не тормозит, только иногда слышен звук раскручивающегося диска, но тормозов при этом нет.

Попробовала сделать, то что вы предлагаете:
[root@linux ~]# !/bin/bash
-bash: !/bin/bash: event not found

Как быть?
И поможет ли это сделать режим APM_level   = off навсегда? :)

Оффлайн bormant

  • Участник
  • *
  • Сообщений: 358
Вот теперь запомните временную отметку последней строчки, отправьте в (или дождитесь) ждущий режим, после возврата выполните dmesg и посмотрите, добавилось ли там что-то интересное после запомненной строки.

/var/log/messages -- это не команда, а текстовый файл (точнее, ссылка на /var/log/syslog/messages), его можно посмотреть от root или члена группы adm (права у него такие). Посмотреть хвост довольно просто:
# tail /var/log/messages -n 20
после -n -- количество строк, подробности традиционно в man tail.

Можно легко проверить, виноват ли pm-utils.
1) выполнить
export DRIVE_POWER_MGMT_BAT=254
или (менее предпочтительно) 2) от root в файле /usr/lib/pm-utils поменять строчку
DRIVE_POWER_MGMT_BAT="${DRIVE_POWER_MGMT_BAT:-1}"
на
DRIVE_POWER_MGMT_BAT="${DRIVE_POWER_MGMT_BAT:-254}"

Затем отправить в ждущий режим и после возврата проверить
# hdparm -B /dev/sda
# echo $DRIVE_POWER_MGMT_BAT

Если получим
APM_level   = off
254
значит виновник найден. Фиксируем результат: в /etc/rc.d/rc.local добавляем
export DRIVE_POWER_MGMT_BAT=254
перегружаемся и после выхода их ждущего/спящего режима проверяем (как -- показано выше) и параметр энергосбережения, и значение переменной DRIVE_POWER_MGMT_BAT.

Правда, эта настройка по замыслу разработчиков должна срабатывать при переходе на питание от батареи. 
Возможно, режим энергосбережения меняет кто-то ещё, нужно будет искать дальше.

Ход рассуждений:
# rpm -q pm-utils --list # список файлов пакета
/usr/lib/pm-utils/...
...
# grep -lR hdparm /usr/lib/pm-utils/
/usr/lib/pm-utils/power.d/harddrive

ps.
Попробовала сделать, то что вы предлагаете:
[root@linux ~]# !/bin/bash
-bash: !/bin/bash: event not found
И поможет ли это сделать режим APM_level   = off навсегда? :)
1) Это была не команда, а содержимое файла /etc/rc.d/rc.local
Первая строка "#!/bin/bash" -- shebang, комментарий-указание на то, что файл является скриптом bash (/bin/bash), а не какого-то другого интерпретатора (например, /bin/perl).
2) Не поможет, поскольку этот файл исполняется только при старте системы, а параметры меняются при выходе из ждущего/спящего режима.
« Последнее редактирование: 08.12.2011 12:11:12 от bormant »

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 169
    • Домашняя страница
Следите за http://git.altlinux.org/tasks/59790/
В p6 собирается Firefox 8.0. Ночью, возможно, будет на FTP и доступен для обновлений.
Андрей Черепанов (cas@)

Оффлайн bormant

  • Участник
  • *
  • Сообщений: 358
Skull,
пожалуй, сообщение про Firefox было адресовано в другую тему?

Оффлайн Skull

  • Глобальный модератор
  • *****
  • Сообщений: 20 169
    • Домашняя страница
Skull,
пожалуй, сообщение про Firefox было адресовано в другую тему?
Нет, в эту. Забыл добавить цитату:
Смотрю свою - 7.0.1. Если я правильно понимаю, обновляться она должна автоматически из репозитория.
Или мне нужно что-то самостоятельно еще проделать, чтобы ее обновить до последней версии?
Андрей Черепанов (cas@)