Я расширял память с 8 до 16, когда потребности возросли, поэтому я загуглил) А при покупке нового -- на спеки проца, наличие модулей нужного размера в продаже, сервис мануал конкретоного ноута (чтобы убедиться, что там два слота), нормальную фирму, которая не зажимает максимальное количество памяти искусственно (привет, HP!) и, в идеале, отзывы тех, кто уже брал.
Идёте на сайт intel'а, находите datasheet на семейство и смотрите в раздел system memory support, там сказано, что поддерживает конкретное семейство процессоров. Например, на актуальное i7-7xxxHQ -- https://www.intel.com/content/www/us/en/processors... там ищем раздел system memory interface.
Судя по приведённому в нём тексте и табличке на тот же i7-7700HQ можно ставить планки максимум в 16 GiB (с технормой чипа RAM 8Gb, коих на планке максимум 16, если она двусторонняя, что даёт 16 GiB), но по две на канал. Т.е. при наличии двух слотов вы сможете поставить 32 GiB, при наличии 4 -- 64 GiB, что является максимумом для этого проца. Другое дело, что четыре слота будет на мобильных рабочих станциях, а не на большинству ноутбуков.
На lenovo х220 с i5-2520M производитель указывал поддержку до 8 GiB, у меня -- 16 GiB. Как я не заметил, что производитель прав, когда у меня нередко занято 12-14 GiB памяти?
Во-первых, я писал про ноуты, где в лучшем случае два слота (и на новых процах до 32 GiB DDR4, а на чуть более старых 16 GiB DDR3). Так можно десктопные матери с максимумом в 128 GiB сравнить с серверными, где 512 GiB на сокет запросто.
Во-вторых, больше чем камень поддерживает всё равно не поставишь)
Меняйте диски, в первую очередь. Если у вас зеркало, то можно выдернуть один диск (через mdadm /dev/mdX -f /dev/sdaXY) и посмотреть на работу на втором. Крайне желательно при этом иметь подключенный KVM и какой-нибудь rescue-образ под рукой.
Пробовали ли вы воспользоваться рекомендациями от @brutal_lobster?
Переносите данные на новый диск. Скорее всего, проблема с дисками.
У меня недавно попался один seagate, который вёл себя, как живой, но при наличии его в рейде -- не давал запустить систему: то udev упадёт при загрузке, то sssd+slapd не отзываются.
Спецификация MIME (я так понимаю, что вы имеете ввиду RFC 822-5322 и сопутствующие) вполне однозначна и почтовые сообщения хорошо парсится в теории. В реальном всё совсем не так.
Поэтому хранение оригиналов вполне оправдано.
Книги на pragbook.ru, мягко говоря, отстают от жизни. Например, Agile Web Development with Rails (перевод выполнен издательством Питер) описывает Rails 3.1, после которого эта книга (в оригинале) выходила для версии 3.2 (2012-08) и 4.0 (актуальной, 2013-10).
При проблемах с acpi запущенный acpid может создавать проблемы, но это диагностировать сложно.
Попробуйте погонять какие-нибудь дисковые операции (dd if=/dev/null of=/some-tmp-file oflag=direct bs=1M), посмотрите на производительность.
Можно глянуть tail -n 1000 /var/log/messages. Если у вас логгирование не очень плотное, то хватит. Если плотное -- то выдернуть кусок около момента перезагрузки.
Ещё может быть полезно посмотреть на показания сенсоров. Учитывая, что эти товарищи любят десктопное железо -- хз что там с температурными режимами.
Загоните выхлоп dmesg'а под спойлер. И выложите /var/log/messages.
Orphaned inode у вас скорее всего после ребута. Проблемные записи по acpi были и раньше или добавлялось какое-нибудь оборудование? Запущен ли acpid?
Я бы также предложил заглянуть в /proc/mdstat, smart дисков, прогнать smart-тесты (smartctl --test=long /dev/sdX): у хетзнера бывают проблемы с дисками. Не было ли последнее время просадки производительности на дисковых операциях?
На русском лучше книг не ждать, а читать сразу в оригинале. Та же Programming Ruby написана вполне простым языком.
Переводы по рельсам, которые я видел после выхода 3.2 (начало 2012) были в лучшем случае по 2.3 (вышедшие в начале 2009).
При это Agile Web Development with Rails обновлялась по ходу стабилизации Rails 4 (писалась в процессе выхода 4 в бету): книга была уже в бете к моменту RC рельс и в RC к моменту релиза рельс.
Ну и про рельсы стоит смотреть на ещё два источника, как минимум: guides.rubyonrails.org и railscasts.com (платная подписка не обязательна, но может быть полезна). Первый -- официальная документация, второе -- куча обзоров новых и полезных вещей, всякие best practice и прочее.
Этот вариант озвучен в виде "параметризация на этапе сборки". Можно, например, базовый war указать в качестве runtime-зависимости. Файлы в текущем модуле могут оверрайдить исходные.
Довольно неприятно, что в разных протоколах используются совершенно разные способы кодирования (в MIME, HTTP, HTTP headers, LDAP).
Сам по себе MIME не так страшен. Куда страшнее, что некоторые товарищи (IBM и MS) преспокойно кладут на этот самый MIME. Вот тогда разбор сообщений становится адом.
Примеры:
1. некодированные данные в заголовках,
2. дублирование заголовков (например, 2 заголовка Subject, в одном данные в cp1251, во втором — в utf8, ичсх оба незакодированы),
3. разрезание адреса на части и кодирование в формате =?UTF-8?B?.....?= кусков email'а с угловыми скобками, а не имени отправителя/получателя,
4. несоответствие Content-Transfer-Encoding и реального способа кодирования.
Это из того, что вспомнил сходу. Но там ещё много разных «приятных» мелочей.
