В каком смысле, как его "Using"? Автоматическая оптимизация выполнения, вроде index intersect. Если запрос выполняется часто, то тюнить настройки памяти, чтобы необходимые данные были в кэше, а не читались с диска. Если explain с прогретой машинки, значит данные в буфера катастрофически не влезают и вытесняются слишком быстро.
Проверяйте конденсаторы. В первую очередь в блоке питания.
Хорошие модели у seasonic, enhance
Приличные у Corsair
Крепкие рабочие лошадки - FSP. Бывают несколько шумными и с короткими кабелями.
По остальным надо смотреть конкретные модели.
По мощности - без разгона 30-35А по +12В линиям за глаза хватит.
df - это смонтированные файловые системы, а не все блочные устройства. Смонтированные разделы os-prober и не будет пытаться монтировать.
От file странная реакция, утверждает, что это не разделы, а блочные устройства со своей таблицей разделов. И говорит, что MBR, но начинается со второго сектора - это странно.
По ответу похоже, что вы не только не знаете, как размечены ваши диски, но и что на них вообще находится.
Значит, если раздел не используется - его можно рассматривать как бинарный мусор и анализировать содержимое бессмысленно. Ну, os-prober этого не знает и пробует читать.
Вопрос-то в чём?
Что вызывает эти сообщения? Гипотеза дана. Грохните os-prober и проверьте.
В порядке ли ваши расходники - так расходники и проверяйте. man badblocks, smartmontools
Ну да, фактически всё время - это Planning time. Что с ним делать - не использовать много партиций и ждать. Конкретных релизов пока нет, но в сторону более нормального партицирования разработчики движутся.
А зачем вам партицирование вообще? Что хотите его использованием добиться? Основные причины:
- сокращение размера индексов
- простые и лёгкие удаление и очищение ненужных разделов
По второму пункту добавить мне нечего - с такими задачами не сталкивался, что нужно удалять много данных, часто и быстро.
По первому - можете использовать partial index https://www.postgresql.org/docs/9.4/static/indexes...
В том-то и загвоздка, что подобные, а не такая же и помногу раз в секунду, чтобы имело явный смысл запариться и считать на стороне СУБД. В следующий раз надо будет заменить что-нибудь другое в другом месте - и обработчик для этой задачи подойдёт чуть менее чем никак.
А знакомый язык, да с полноценными регулярками - простое и понятное решение. СУБД может помочь с предварительным фильтром, чтобы не обрабатывать данные, в которых подстроки и нет вообще.
Кого поставить на апач? Наверняка ваш nginx уже собран с этим модулем, как, например, в репозиториях debian. Вот и допишите в конфиг использование этого модуля. Ну а если не собран - то придётся пересобрать кастомный nginx.
Клонировать каждый объект коллекции в отдельности. Например,
public static function getItems(){
return array_map(function($el) {
return clone $el;
}, self::$arItems;
}
Статический класс здесь значения не имеет. По ссылке передаются сами stdClass
WeReng: это расходник. Всегда считайте, что можете в любой случайный момент времени потерять все на него записанные данные.
Плюсы и минусы:
сдать по гарантии - до 45 суток его могут держать в СЦ согласно этому самому ЗоЗПП (насчёт условий выдачи подмены на этот срок не помню точно, надо уточнять). Минимум и в среднем - в зависимости от СЦ. Есть вероятность, что они сами запустят это же самое восстановление, диск исправится и его же вам вернут через пару дней. Но есть и вероятность, что диск вам заменят на новый с новой гарантией.
запустить программу самому - соответственно, если поможет, то у вас уже не будет повода обращаться в СЦ. Если не поможет - то в СЦ всё равно (и повыше вероятность замены).
Вот по-моему и вся разница.
