Инструменты пользователя

Инструменты сайта


diagnostika

Различия

Здесь показаны различия между двумя версиями данной страницы.

Ссылка на это сравнение

diagnostika [2018/07/19 06:58] (текущий)
Строка 1: Строка 1:
 +====== Диагностика ======
 +  * [[SMART]] - технология внутренней оценки состояния жёсткого диска([[HDD]]);​ а также механизм предсказания возможного выхода его из строя.
 +  * [[RAID]] - мониторинг,​ диагностика HDD.
 +  * [[Диагностика HDD (НЖМД) на работающих системах]]:​ [[smartmontools]].
 +  * [[sysctl]]
 +  * [[http://​habrahabr.ru/​post/​71020/​|Load average]] - высокие значения показателей говорят о том, что система не справляется с нагрузкой([[top]]).
 +  * [[http://​www.opennet.ru/​tips/​2784_linux_server_troubleshooting_monitoring_debug.shtml|Первые 5 минут устранения неполадок на Linux-сервере]]
  
 +
 +====== Инструменты системного администрирования ======
 +  * WAN:
 +      * [[fping]] - расширение стандартной утилиты [[ping]]
 +  * Интерактивные просмотрщики процессов:​
 +      * [[top]] - Linux, BSD
 +      * [[htop]] - Linux;
 +      * **slabtop** - display kernel slab cache information in real time. Выводит информацию о состоянии внутренних буферов,​ кэшей Linux ядра, доступных через /​proc/​slabinfo. Например,​ для вывода заполненных кешей<​file>​
 +# slabtop --sort u
 +</​file>​
 +      * [[atop]]
 +      * [[dstat]] объединяет в себе возможности [[vmstat]], [[iostat]] и ifstat.
 +  * Сетевая статистика:​
 +      * [[netstat]] - сетевая статистика
 +      * [[ss]] - сетевая статистика
 +      * [[tcpdump]] + графический интерфейс wireshark
 +      * ifstat - статистика сетевых интерфейсов
 +  * Производительность системы:​
 +      * [[vmstat]] - определение производительности системы.
 +      * [[free]]
 +      * Пакет **sysstat** состоит из следующих утилит измерения производительности системы:​
 +            * [[sar]] - собирает и выдаёт информацию о системной активности;​ в реальной жизни часто бывает,​ что требуется посмотреть [[vmstat]] на агонизирующей системе,​ когда что-либо понять и исправить уже поздно,​ или даже уже после того, как систему перезагрузили. Это возможно. Достаточно заблаговременно установить в систему программу sar.
 +            * [[iostat]] - сообщает об использовании ЦП и статистику В/В дисков;​
 +            * mpstat - сообщает глобальную и по-процессорную статистику;​
 +            * pidstat - сообщает статистику по Linux задачам (процессам);​
 +            * sadf - отображает информацию,​ собранную sar, в различных форматах.
 +            * [[iotop]]
 +  * [[Iperf]] - кроссплатформенная консольная клиент-серверная программа — генератор TCP и UDP трафика для тестирования пропускной способности сети.
 +  * [[screen]]
 +  * **slmon** - простой монитор системной производительности: ​ CPU load (SMP is supported), memory and swap load, uptime, date and time, number of logged in users, network traffic
 +  * [[ps]]
 +  * [[lshw]] содержит в себе [[lspci]] и [[lsusb]] - определение оборудования компьютера
 +  * [[Expect]] - инструмент для автоматизации интерактивных приложений таких, как telnet, ftp, passwd, [[fsck]], rlogin, tip, [[ssh]] и других.
 +  * [[time]] - измеряет время выполнения отдельной программы и затраченное на ее выполнение время ЦП.
 +
 +===== Цели оценки производительности =====
 +Для оценки и настройки производительности системы важно правильно понимать,​ что вкладывается в понятие рабочей схемы. Изменение рабочей схемы зачастую оказывает намного большее влияние на производительность системы,​ чем изменение быстродействия процессора или размера оперативной памяти. Понятие рабочей схемы включает в себя не только тип и число запросов к системе,​ но и набор установленных пакетов программного обеспечения,​ а также набор локальных прикладных программ.
 +
 +  * Получите информацию о том, с какой скоростью выполняются приложения,​ с которыми пользователи работают на своих рабочих станциях и терминалах.
 +  * Убедитесь в том, что вы учитываете действия,​ которые система выполняет неявно. Например,​ если некоторые файловые системы могут удаленно монтироваться с помощью NFS, и к ним часто обращаются пользователи других систем,​ то значительная часть ресурсов системы может затрачиваться на обработку запросов к этим файловым системам,​ даже если эта система не считается сервером.
 +
 +После определения рабочей схемы, в которой будут исследоваться системы,​ вы можете выбрать критерий,​ по которому системы будут оцениваться,​ и установить цели отбора на основе этого критерия. Основными критериями оценки производительности является время ответа и эффективность работы.
 +
 +  * **Время ответа** - это время, через которое выдается ответ на отправленный запрос. Примером может служить время обработки запроса к базе данных,​ задержка в копировании символов на терминал или время загрузки Web- страницы.
 +  * **Эффективность работы** определяется объемом работы,​ выполняемой за единицу времени. Другими словами,​ это число операций рабочей схемы, которые выполняются за единицу времени. Примером может служить число транзакций,​ выполняемых в минуту,​ объем данных,​ считываемых из файла или передаваемых по сети за секунду,​ либо число документов,​ найденных на Web- сервере за минуту.
 +
 +Связи между этими показателями достаточно сложны. В одних случаях значение одного показателя можно улучшить только за счет другого показателя. В других случаях определенные изменения могут улучшить обе величины. Довольно часто можно добиться высокой эффективности работы системы за счет увеличения времени ответа,​ либо уменьшения времени ответа за счет снижения эффективности работы. Оптимальной считается производительность,​ при которой значения обоих показателей приемлемы.
 +
 +<note important>​При подготовке к настройке производительности системы определите время ответа и эффективность работы системы,​ которых необходимо добиться при обработке рабочей схемы. В противном случае вы можете потратить время и деньги на оптимизацию несущественных аспектов производительности системы.</​note>​
 +
 +
 +**Стандартные тесты**.
 +
 +Тестом называется рабочая схема, позволяющая сравнивать производительность различных систем. Все стандартные тесты тщательно изучены разработчиками систем. Операционные системы,​ компиляторы и, в ряде случаев,​ аппаратное обеспечение,​ могли быть спроектированы так, чтобы такие тесты выполнялись с отличными показателями. К сожалению,​ реальные нагрузки редко повторяют алгоритмы и требования стандартного теста. Даже те тесты, которые были созданы на основе реальных приложений,​ часто упрощаются и стандартизируются таким образом,​ чтобы они могли выполняться на различных аппаратных платформах. Среды, в которых запускаются такие тесты, имеют ряд искусственных ограничений,​ которые были созданы для того, чтобы измерения давали воспроизводимые результаты. Любое утверждение типа "​Система A выполняет тест MegaThings на 50 процентов быстрее,​ чем система B, поэтому система A будет выполнять ваши программы на 50 процентов быстрее,​ чем система B" выглядит довольно убедительно,​ но на самом деле не является точным. Настолько универсального теста не существует. **Единственное применение стандартных тестов производительности - это грубый отбор систем для дальнейшего тщательного тестирования.** Единственным решением является составление точного описания своей рабочей схемы и оценка скорости ее выполнения в различных системах.
 +
 +**Процесс анализа производительности бесконечен**,​ поскольку с течением времени в системе всегда появляется другой ресурс,​ ограничивающий производительность. Снижение потребности в одном ресурсе означает,​ что теперь пропускная способность и время отклика будет ограничиваться другим ресурсом. Предположим,​ что в системе ресурсы используются следующим образом:​
 +<​file>​
 +Процессор:​ 90% Диск: 70% Память:​ 60%
 +</​file>​
 +Работа такой системы зависит от скорости процессора. Если вам удастся настроить рабочую схему таким образом,​ что значение показателя использования процессора сократится с 90 до 45 процентов,​ то вы вправе ожидать,​ что производительность возрастет в два раза. Однако на деле получится,​ что теперь производительность системы ограничена скоростью дискового ввода-вывода,​ а показатели использования ресурсов станут примерно следующими:​
 +<​file>​
 +Процессор:​ 45% Диск: 90% Память:​ 60%
 +</​file>​
 +Снижение нагрузки на процессор позволяет программам быстрее передавать запросы на общение к диску, в результате чего может быть достигнуто ограничение на использование диска. В результате производительность возрастет всего лишь на 30 процентов,​ а не на 100.
 +
 +Ресурсы,​ которые ограничивают производительность,​ есть всегда. Важно лишь то, достигнуты ли цели оптимизации с помощью имеющихся в наличии ресурсов.
 +===== Что подлежит проверке?​ =====
 +  * **Hardware**.
 +       * Жесткие диски ([[HDD]]). ([[iostat]],​ [[iotop]], [[vmstat]], [[sar]], [[hdparm]], [[smartmontools|smartctl]]). При выполнении программы больше всего времени затрачивается на считывание исходного кода и данных программы с жесткого диска. Обращения к диску могут быть вызваны не только явными запросами прикладной программы. Иногда настройка системы может привести к выполнению ненужных операций дискового ввода-вывода.
 +
 +Сбор информации о дисковом вводе-выводе применяется при решении следующих задач:
 +
 +  * Поиск наиболее интенсивно используемых файлов,​ файловых систем и логических томов:
 +        * ([[iostat]]). Можно ли лучше расположить или распределить интенсивно используемые файловые системы по нескольким физическим накопителям?​
 +        * Расположены ли интенсивно используемые файлы в локальной или удаленной системе?​
 +        * ([[vmstat]]) Не занята ли большая часть дисковой памяти пространством подкачки?​
 +        * ([[vmstat]]) Достаточен ли размер кэша для хранения всех обновляемых процессами страниц?​
 +        * Какую долю дискового ввода-вывода составляют синхронные операции (без кэширования)?​
 +  * Определение фрагментации файлов:​
 +        * Насколько фрагментированы интенсивно используемые файлы?
 +        * ([[iostat]]). Поиск наиболее часто используемого физического тома: не является ли применяемый накопитель или контроллер узким местом в работе системы?​
 +
 +       * [[ЦП]]. ([[vmstat]]). Одна программа редко способна полностью загрузить процессор (когда процессор не совсем не простаивает и не находится в состоянии ожидания) больше чем на несколько секунд. Даже в многопользовательских системах с большой нагрузкой иногда возникают периоды длительностью 10 миллисекунд,​ когда все нити находятся в состоянии ожидания. Если в выводе монитора указано,​ что процессор загружен на 100 процентов в течение длительного времени,​ то, скорее всего, одна из программ зациклилась. Даже если программа не содержит ошибку,​ а просто потребляет много процессорного времени,​ необходимо изменить ее алгоритм.  ​
 +       * [[ОЗУ]]. ([[vmstat]],​ [[ps]]). [[Shared memory]]. Операционные системы стараются хранить в оперативной памяти только те инструкции и данные,​ которые используются в текущий момент,​ выгружая ненужную информацию на диск (или вообще не загружая ее в память). При обращении к странице виртуальной памяти,​ выгруженной на диск (или еще не загруженной в оперативную память),​ возникает страничная ошибка,​ и выполнение программы прерывается до тех пор, пока страница не будет считана с диска. Оперативная память системы почти все время заполнена. Даже если текущие выполняемые программы не занимают все пространство памяти,​ операционная система хранит в ней страницы программ,​ выполнявшихся ранее, и файлы, которые применялись этими программами. Такое хранение не требует затрат,​ поскольку в противном случае память все равно бы не использовалась. Вместе с тем вполне возможно,​ что программы или файлы понадобятся вновь, и тогда они будут обработаны значительно быстрее. WIO - процессорное время, затраченное на ожидание дискового ввода-вывода,​ можно просмотреть с помощью команд [[sar]] (%iowait), [[vmstat]] (wa) и [[iostat]] (%iowait).
 +       * [[TLB]] Для того чтобы уменьшить время, затрачиваемое на преобразование адресов,​ физические адреса тех страниц виртуальной памяти,​ к которым обращались в последнее время, хранятся в кэше, который называется таблицей преобразования адресов (TLB). До тех пор пока программа обращается к небольшому числу страниц виртуальной памяти,​ полное преобразование виртуальных адресов не производится. Если программа обращается к странице,​ для которой в таблице TLB отсутствует запись (промах TLB), то на преобразование адреса затрачивается порядка десяти тактов процессора (время обработки промаха TLB).
 +       * **Кэш**. Для минимизации задержек,​ связанных с обращением к оперативной памяти,​ в системе предусмотрен кэш для команд и данных. Если необходимые команды или данные находятся в кэше (попадание),​ то они будут переданы процессору уже на следующем такте (другими словами,​ задержки не будет). В противном случае некоторое время будет затрачено на обращение к оперативной памяти (промах кэша). В некоторых системах кэши имеют несколько уровней:​ L1, L2 и L3. Если необходимые данные не будут найдены в кэше L1, то система попытается найти их в кэше L2. В случае промаха в кэше L2 система переходит на уровень L3 (если он есть) или к оперативной памяти.
 +       * **Конвейер,​ регистры**.
 +       * **Производительность сети**. ([[ping]], [[ftp]], [[netstat]] -s, [[ethtool]] -S). [[TCP]]/IP, [[UDP]], [[Ethernet]]. При настройке соединения может преследоваться одна из двух целей: **повысить его пропускную способность** или **сократить расход памяти**. //Если необходимая пропускная способность всех узлов локальной сети составляет более 70 процентов от номинальной (50 процентов для Ethernet), то потребуется увеличить пропускную способность сети.// Причина возникновения проблем производительности может находиться не в системе,​ во многих километрах от нее. Для того чтобы определить,​ лежит ли причина недостаточной производительности в сети, можно сравнить выполнение зависящих от сети операций с операциями,​ проходящими без участия сети. Если программа,​ выполняющая много операций удаленного чтения и записи,​ работает медленно,​ а все остальные программы выполняются нормально,​ возможно,​ причина находится в сети. Наиболее часто возникающие узкие места в сети:
 +        * Сетевой интерфейс клиента
 +        * Пропускная способность сети
 +        * Топология сети
 +        * Сетевой интерфейс сервера
 +        * Процессор сервера
 +        * Память сервера
 +        * Производительность сервера
 +        * Неэффективная настройка ​
 +Существует множество параметров сети, которые могут быть измерены специальными средствами,​ но только часть из этих параметров важны для настройки производительности.
 +
 +В каких случаях нужно увеличить значения параметров очередей приема и передачи?​
 +
 +Ниже описаны случаи,​ в которых рекомендуется увеличить значения параметров очередей приема и передачи:​
 +  * Если CPU работает намного быстрее,​ чем сеть, или по одной сети передают данные несколько приложений. Обычно это характерно для больших многопроцессорных систем (SMP).
 +  * Если для параметров tcp_sendspace и tcp_recvspace установлены большие значения. Они могут быть установлены например приложениями,​ которые посредством системных вызовов увеличивают объем буферов приема и передачи протокола TCP. В этом случае CPU может одновременно отправить адаптеру большое количество пакетов. Аналогичная ситуация может возникнуть при изменении параметров udp_sendspace и udp_recvspace протокола UDP.
 +  * При резком возрастании плотности потока данных.
 +  * При отправке небольших пакетов нагрузка на сеть выше, чем при отправке больших сообщений. Это связано с тем, что передача больших сообщений по сети занимает большее время. Соответственно,​ за единицу времени будет передаваться меньшее число сообщений. ​
 +
 +  * **Software**. Ресурсы,​ используемые конкретным процессом,​ определить довольно сложно. Это не только техническая,​ но также и методическая трудность. Если разные экземпляры данной программы,​ запущенные несколькими пользователями,​ совместно обращаются к одним и тем же страницам текста программы,​ то к какому процессу нужно относить использование этих страниц памяти?​ Операционная система хранит в кэш- памяти страницы файлов,​ использованные недавно,​ чтобы программы могли повторно обращаться в этим данным. Если программа несколько раз обращается к одним и тем же данным,​ то следует ли учитывать тот объем памяти,​ который использовался для хранения этих данных?​ Точность некоторых измерений,​ например,​ показаний системных часов, может привести к сложностям при оценке времени использования CPU последовательно запускаемыми экземплярами одной и той же программы. Существует два подхода к анализу неоднозначных данных,​ содержащихся в отчете об использовании ресурсов. Первый основан на том, что неопределенности игнорируются,​ а изменяющиеся величины исключаются из рассмотрения до тех пор, пока в результате измерений не начнут поступать согласованные данные. При втором подходе по возможности измеряются реальные параметры,​ а для описания результатов применяются статистические методы. Второй подход позволяет получить результаты,​ которые больше соответствуют реальным условиям. Случаи,​ когда в системе выполняется только одна программа,​ очень редки. Обычно в системе выполняются несколько демонов,​ обслуживаются активные соединения и одновременно работают несколько пользователей. При этом зависимость объема занятых ресурсов от числа выполняемых операций не линейная. Например,​ увеличение числа экземпляров программы может привести к использованию только нескольких новых страниц текста программы,​ поскольку большая часть программы уже была в памяти. В то же время, новый процесс может усилить конкуренцию за использование кэш- памяти процессора. Следовательно,​ он не только увеличивает конкуренцию за процессорное время, но и приводит к тому, что увеличивается время, затрачиваемое на выполнение одной команды. Это связано с возрастанием числа промахов в кэше, и в итоге приводит к снижению скорости выполнения всех процессов. **В общем случае закономерность такова:​ чем выше уровень абстракции программы (например программа написана с использованием perl, awk и/или bash), тем сложнее гарантировать,​ что не возникнет никаких неожиданных проблем с производительностью.**
 +       * **Исполняемые программы**
 +       * **Обработчики прерываний**. Для оповещения операционной системы о каком-либо внешнем событии применяется механизм прерываний,​ который позволяет приостановить выполнение текущей нити и передать управление обработчику прерываний. Перед запуском обработчика прерываний сохраняется информация о состоянии аппаратных компонентов,​ чтобы после обработки прерывания система могла восстановить среду выполнения нити. На работе обработчика прерываний сказываются те же задержки,​ связанные с перемещением по аппаратной иерархии,​ что и на работе обычных программ (исключение составляют страничные ошибки). Если обработчик прерываний вызывался достаточно давно (и программа не является крайне экономной по отношению к ресурсам),​ то маловероятно,​ что его код или дата сохранятся в [[TLB]] или кэш- памяти. Когда прерванная нить снова передается на выполнение,​ ее контекст (в частности,​ содержимое регистров) восстанавливается,​ поэтому она может продолжить свою работу. При этом содержание TLB и кэш-памяти формируется на основе последующих запросов программы. Таким образом,​ и в обработчике прерываний,​ и в прерванной программе будут возникать серьезные задержки,​ связанные с промахами при обращении к кэшу и TLB.
 +       * **Ожидающие нити**. Если запрос программы нельзя обработать немедленно,​ (например,​ операцию ввода-вывода нельзя выполнить из-за страничной ошибки),​ то до окончания обработки запроса нить переходит в состояние ожидания. Как правило,​ это приводит к дополнительным задержкам при работе с TLB и кэшем, не считая самого времени обработки запроса.
 +       * **Нити, готовые к выполнению**. Нить, ожидающая передачи на выполнение,​ фактически простаивает. Кроме того, для выполнения текущих нитей в кэше могут быть удалены данные нити, ожидающей передачи на выполнение,​ а из оперативной памяти могут быть выгружены ее страницы данных. Следовательно,​ когда нить будет передана на выполнение,​ возникнут дополнительные задержки при обращении к кэшу и оперативной памяти.
 +       * **Нити, выполняемые в данный момент**.
 +       * **Инструкции,​ выполняемые в настоящий момент**. Большинство машинных инструкций выполняются за один такт процессора,​ если при обращении к TLB или кэшу не возникнет промах. Однако если часто выполняется переход к различным частям программы,​ а данные считываются из различных областей памяти,​ то при обращении к TLB и кэшу возникает большое число промахов. В результате число тактов процессора,​ затрачиваемых на выполнение одной инструкции (CPI), может быть намного больше единицы. В этом случае говорят,​ что в программе ссылки расположены не компактно. Даже если программа содержит небольшое число инструкций,​ на их выполнение может быть затрачено довольно много тактов процессора. Это одна из причин,​ по которой нельзя оценить время выполнения программы,​ подсчитав число инструкций. Как правило,​ чем короче программа,​ тем быстрее она выполняется,​ однако размер программы не прямо пропорционален времени ее выполнения. Компилятор оптимизирует код программы таким образом,​ чтобы минимизировать число тактов процессора,​ необходимых на выполнение программы. Для того чтобы добиться максимальной производительности программы,​ нужно предоставить компилятору полную информацию,​ необходимую для эффективной оптимизации,​ а не строить предположения о том, какой способ оптимизации будет выбран компилятором.
 +
 +====== Сетевая подсистема Linux ======
 +  * [[wpru>​Сетевая плата]]
 +  * [[OSI]]
 +  * [[http://​www.opennet.ru/​docs/​RUS/​GigabitEthernet/​|Настройка Gigabit Ethernet в ОС GNU/Linux и FreeBSD]]
 +  * [[http://​habrahabr.ru/​blogs/​sysadm/​108763/​|Большие потоки трафика и Linux: прерывания,​ маршрутизатор и NAT-сервер]]
 +  * [[http://​habrahabr.ru/​blogs/​sysadm/​108240/​|Большие потоки трафика и управление прерываниями в Linux]]
 +  * [[Ethernet]]
 +  * [[ifconfig]]
 +  * [[ethtool]]
 +  * [[netstat]] -i
 +  * [[IPv4]]
 +  * [[TCP]]
 +  * [[UDP]]
 +
 +  * **Буфер сетевой подсистемы Linux**
 +Драйвер сетевой карты переправляет принятые пакеты в буфер сетевой подсистемы. Все передаваемые и принимаемые пакеты в сетевой подсистеме Linux хранятся и обрабатываются в специальных типовых буферах,​ называемых структурами буфера сокетов (struct sk_buff). Имеющиеся в памяти буферы организованы в очередь,​ которая управляется ОС. В случае,​ если нужно разместить поступивший в сетевую подсистему пакет, а существующие буфера заполнены данными,​ система выделяет в памяти место под новый буфер. Когда пакет обработан и надобности в нём больше нет, буфер не уничтожается,​ а помечается как свободный и может быть использован для размещения вновь поступившего пакета. Таким образом,​ обычно в системе существует некоторое количество свободных буферов,​ которые могут быть использованы для обмена пакетами с сетевыми интерфейсами.
 +
 +Каждое ТСР- соединение требует наличия приемного и передающего буфера,​ тогда как для входящих UDP-соединений требуется только приёмный буфер.
 +
 +<note important>​Большой объём буфера часто может улучшить работу сети TCP, но также будет потреблять больше памяти.</​note>​
 +
 +  * **Polling режим**.
 +Сетевые карты - устройства,​ управляемые прерываниями,​ то есть при получении пакета будет вызвано прерывание,​так что драйвер знает, что есть пакет, который будет обработан. Как уже говорилось ранее, для загруженой системы,​ большой трафик,​ а соответственно и большое количество прерываний может стать проблемой. В Polling - режиме ​  ​сетевая карта никогда не генерирует прерывание,​ а ждет, когда ОС опросит карту, накапливая тем временем информацю в буфере и надеясь,​ что он не переполнится. Этот Polling - драйвер обычно вызывается между двумя процессами,​ таким образом сокращающая время контекстного переключения. Хорошие драйвера могли бы переключать между IRQ и pollinfg режимами в случае если работа по прерываниям обнаруживает несколько раз подряд пустой буфер, и обратно,​ если буфер начинает переполняться.
 +====== Fedora p4-clockmod:​ Warning: EST-capable CPU detected ======
 +**OC: Fedora 13 (Goddard) Linux 2.6.34.9-69.fc13.x86_64.**
 +
 +Утилита dmesg выводит для каждого ядра [[процессор|процессора]] сообщение:<​file>​
 +p4-clockmod:​ Warning: EST-capable CPU detected.
 +The acpi-cpufreq module offers voltage scaling in addition of frequency scaling.
 +You should use that instead of p4-clockmod,​ if possible.
 +</​file>​
 +Это сообщение связано с [[https://​wiki.archlinux.org/​index.php/​CPU_Frequency_Scaling_(%D0%A0%D1%83%D1%81%D1%81%D0%BA%D0%B8%D0%B9)|CPU Frequency Scaling]] - утилитами для масштабирования частоты процессора,​ для анализа можно использовать **powertop** и **cpufreq-info** (из пакета cpufrequtils).
 +
 +Модуль ядра p4-clockmod поддерживает только performance и powersave регуляторов. Для процессоров Intel рекомендуется модуль acpi-cpufreq. Варианты модулей можно найти здесь:
 +<​file>​
 +# ls /​lib/​modules/​$(uname -r)/​kernel/​arch/​x86/​kernel/​cpu/​cpufreq/​
 +acpi-cpufreq.ko ​ p4-clockmod.ko ​ pcc-cpufreq.ko ​ powernow-k8.ko ​ speedstep-lib.ko
 +</​file>​
 +Отключим p4-clockmod и загрузим acpi-cpufreq.<​file>​
 +# modprobe -r p4-clockmod
 +# modprobe acpi-cpufreq
 +FATAL: Error inserting acpi_cpufreq (/​lib/​modules/​2.6.34.9-69.fc13.x86_64/​kernel/​arch/​x86/​kernel/​cpu/​cpufreq/​acpi-cpufreq.ko):​ No such device
 +</​file>​
 +Вывод ошибки говорит о том что у нас старый процессор и загрузка модуля acpi-cpufreq невозможно. Проверим какой процессор установлен:<​file>​
 +# cat /​proc/​cpuinfo | grep "model name"
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +model name : Intel(R) Xeon(R) CPU           ​E5410 ​ @ 2.33GHz
 +</​file>​Странно по информации в интернете с этими моделями процессоров работать правильно умеет только модуль acpi-cpufreq. Пробуем загрузить модуль [[wpru>​SpeedStep]]<​file>​
 +# modprobe speedstep-lib
 +</​file>​Загрузился без ошибок.
 +
 +Отключаем загрузку модуля p4-clockmod,​ для этого нужно создать файл как указано ниже или дописать строку в файл blacklist.conf
 +<​file>​
 +# nano /​etc/​modprobe.d/​blacklist-p4-clockmod.conf
 +blacklist p4-clockmod
 +</​file>​
 +<note important>​Для работы модуля acpi-cpufreq в [[BIOS]] должны быть включена поддержка EIST(Enhanced Intel Speedstep Technology).</​note>​
загрузка...
diagnostika.txt · Последние изменения: 2018/07/19 06:58 (внешнее изменение)