cgroups: blkio.weight, кажется, не имеет ожидаемый эффект

Ядро получения работает на том же хосте. Это работает в памяти, что panic'd ядро, зарезервированное, чтобы ядро получения использовало. Ядро получения запускается с kexec механизм паникующим ядром.

/proc/vmcore должен быть обеспечен ядром если его установка для экспорта отображения памяти. Если Ваше ядро не имеет a /proc/vmcore, затем Вы пропускаете правильную инфраструктуру ядра.

Источник ядра Linux подразумевает это /proc/vmcore только заполняется в ядре получения (командная строка ядра, обеспечивающая адрес panic'd ядер vmcore, заголовок ELF требуется), таким образом, /proc/vmcore будет существовать в регулярном ядре, но не будет содержать ничего вообще.

В ядре получения, /proc/vmcore представляет разрушенное ядро как изображение ядра ELF.

Вот некоторый документ RH с большим количеством деталей: https://access.redhat.com/knowledge/solutions/6038

3
28.03.2013, 04:35
2 ответа

Проблема здесь состоит в том, что необходимо использовать справедливый планировщик, я использовал неправильный планировщик и неправильно читал установку (думал, что я использовал справедливый планировщик, но действительно не был). Свопинг к корректному планировщику IO решил проблему.

Изменить планировщик IO (взятый отсюда):

echo cfq > /sys/block/{DEVICE-NAME}/queue/scheduler
4
27.01.2020, 21:20
  • 1
    Примечания по тому, как сделать, который улучшил бы ответ. –  ivotron 08.12.2014, 08:18
  • 2
    Добавленный ссылка при изменении планировщика IO, это является прямым. –  David Parks 08.12.2014, 22:43

Это может быть проблема команды dd с Вашим системным кэшем, имеют Вас, пытался сбросить Ваш кэш сначала:

echo 3 > /proc/sys/vm/drop_caches

И запуск dd управляет с "nocache" опцией?

0
27.01.2020, 21:20

Теги

Похожие вопросы