Тонкая настройка systemd-journald
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
Начнем с места хранения логов. Для сохранения на диск используйте:
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Затем проверьте опции:
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
Опции
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
Классическая ситуация – все место на диске занято логами, либо логи создают излишнюю нагрузку на систему ввода вывода.
Чтобы этого не случилось – логирование нужно настроить в соответствии с реальными потребностями и сегодня мы посмотрим, как это сделать для systemd-journald.
Прежде всего посмотрим текущие настройки, это можно сделать командой:
cat /etc/systemd/journald.conf
По умолчанию все значение в нем закомментированы и представляют настройки службы по умолчанию. Для изменения вы можете использовать данный файл, но официально рекомендуется использовать технологию "drop-ins" и хранить настройки в отдельных файлах.
Создадим для этого директорию:
mkdir -p /etc/systemd/journald.conf.d
А в нем один или несколько файлов с изменениями конфигурации, в нашем случае это будет
00-journal.conf куда мы будем вносить изменившиеся опции.Начнем с места хранения логов. Для сохранения на диск используйте:
Storage=persistent
Это более надежно, чем auto, которое может иногда приводить к сюрпризам. Если же вам не нужна запись логов на диск, но вы хотите иметь их для диагностики и отладки используйте хранение в оперативной памяти. Такой метод рекомендуется для виртуальных машин и контейнеров, а также встраиваемых устройств и мини-ПК.
Storage=volatile
Затем проверьте опции:
Compress=yes
Seal=yes
Первая из них включает сжатие логов, вторая – криптографическую защиту, обычно обе включены по умолчанию.
Хранить логи – это хорошо, но не ограничивать размер – очень плохо, поэтому сразу озаботимся этим:
SystemMaxUse=1G
SystemKeepFree=2G
Первая опция задает максимальный размер хранилища логов, а второй нижний предел свободного места. Таким образом мы будем хранить не более одного гигабайта логов, но при условии, что в системе остается не менее 2 ГБ свободного места.
Если вы храните данные в ОЗУ, то используйте следующие опции аналогичного назначения:
RuntimeMaxUse=64M
RuntimeKeepFree=256M
Опции
SystemMaxFileSize=
SystemMaxFiles=100
Задают максимальный размер одного файла журнала и их общее количество, по умолчанию systemd-journald создает файлы размером 8 МБ.
Для хранения в оперативной памяти аналогичные опции:
RuntimeMaxFileSize=
RuntimeMaxFiles=100
Следующие важные настройки – это уровни логирования, в продуктивных средах нет необходимости хранить логи уровня debug, будет вполне достаточно info или notice. Поэтому замените debug на более низкий уровень логирования в этих трех опциях:
MaxLevelStore=debug
MaxLevelSyslog=debug
MaxLevelSocket=debug
Данный набор опций отвечает за пересылку логов в syslog, kernel buffer, консоль и отправку сообщения пользователям.
ForwardToSyslog=no
ForwardToKMsg=no
ForwardToConsole=no
ForwardToWall=yes
Настройки по умолчанию (указаны выше) оптимальны и без необходимости пересылку включать не следует. Единственная включенная пересылка – это отправка пользователям сообщений уровня emerg (катастрофический сбой).
Еще одна важная опция – это лимиты, позволяющие избегать засорения логов однотипными сообщениями. По умолчанию имеет следующие значения:
RateLimitIntervalSec=30s
RateLimitBurst=10000
Это означает, что в течении 30 секунд можно отправить в лог не более 10 000 сообщений. Обратите внимание, что данный лимит действует для каждого источника событий, а не для всей системы.
В высоконагруженных системах лимит можно повысить, например, для гипервизоров, где виртуалки при старте могут быть достаточно «разговорчивы». В виртуальных средах, наоборот, имеет смысл понизить этот лимит, чтобы избежать массового спама логов сбойным сервисом.
👍31❤6👌1🤣1
Настройка перезапуска пула приложений IIS
IIS, как и любое иное приложение, имеет свои особенности и настройки, некоторые из которых, не будучи известными способны доставить администратору ряд затруднений.
У веб-сервера IIS есть штатная опция перезапуска пула приложений IIS, которая призвана мягко перезапустить пул приложений в целях борьбы с утечками памяти, зависшими сеансами, заблокированными файлами, просроченным кешем и т.д. и т.п.
При использовании IIS совместно в веб-публикацией 1С:Предприятие такое поведение полезно, так как утечки памяти и незавершенные сеансы для этой связки «нормальное» явление.
Но, хотели как лучше – получилось, как всегда. Выяснилось, что 1С:Предприятие не умеет «мягко» перезапускаться на IIS и перезапуск приводит к аварийному завершению сеанса пользователя с потерей несохраненных данных.
Но это еще половина беды, сама 1С выдает сообщение, что «Сеанс завершен администратором». Такая формулировка уже не раз приводила к конфликтным ситуациями, поскольку пользователи думают, что причина сбоя – некоторые действия или технические работы администраторов.
А теперь вишенка на торте – по умолчанию перезапуск пула приложений настроен с интервалом 1740 минут или 29 часов. Это делает процесс для внешнего наблюдателя рандомным и несистематическим.
Пользователя дня два выбрасывает из 1С в рабочее время, время разное, потом снова все хорошо. В системном журнале данные события отображаются со статусом Сведения и ничем не выделяются на общем фоне.
С учетом того, что пользователи редко фиксируют точное время проблемы диагностика «плавающей» неисправности становится весьма затруднительной. Отсюда начинаются слухи о глючности IIS, судорожные попытки миграции на Apache и прочие телодвижения.
Но на самом деле надо просто настроить перезапуск. Обращаем ваше внимание, что его нужно настроить для каждого пула приложений, если их несколько.
Переходим Пулы приложений – Выбранный пул – Дополнительные параметры
Пролистываем до секции Перезапуск, находим там параметр Моменты точного времени для перезапуска и добавляем туда желаемое время перезапуска пула. Мы выбрали для себя 6 часов утра.
Данный параметр представляет из себя массив, и вы можете добавить несколько моментов времени для перезапуска. Также не забывайте про часовой пояс сервера и часовой пояс клиента.
После чего еще ниже находим опцию Постоянный временной интервал (в минутах), которая и была причиной всех наших безобразий и устанавливаем ей значение в ноль.
Изменив значения не забываем перезапустить пул или веб-сервер полностью (ну или ждем пока он сам в очередной раз перезапустится).
IIS, как и любое иное приложение, имеет свои особенности и настройки, некоторые из которых, не будучи известными способны доставить администратору ряд затруднений.
У веб-сервера IIS есть штатная опция перезапуска пула приложений IIS, которая призвана мягко перезапустить пул приложений в целях борьбы с утечками памяти, зависшими сеансами, заблокированными файлами, просроченным кешем и т.д. и т.п.
При использовании IIS совместно в веб-публикацией 1С:Предприятие такое поведение полезно, так как утечки памяти и незавершенные сеансы для этой связки «нормальное» явление.
Но, хотели как лучше – получилось, как всегда. Выяснилось, что 1С:Предприятие не умеет «мягко» перезапускаться на IIS и перезапуск приводит к аварийному завершению сеанса пользователя с потерей несохраненных данных.
Но это еще половина беды, сама 1С выдает сообщение, что «Сеанс завершен администратором». Такая формулировка уже не раз приводила к конфликтным ситуациями, поскольку пользователи думают, что причина сбоя – некоторые действия или технические работы администраторов.
А теперь вишенка на торте – по умолчанию перезапуск пула приложений настроен с интервалом 1740 минут или 29 часов. Это делает процесс для внешнего наблюдателя рандомным и несистематическим.
Пользователя дня два выбрасывает из 1С в рабочее время, время разное, потом снова все хорошо. В системном журнале данные события отображаются со статусом Сведения и ничем не выделяются на общем фоне.
С учетом того, что пользователи редко фиксируют точное время проблемы диагностика «плавающей» неисправности становится весьма затруднительной. Отсюда начинаются слухи о глючности IIS, судорожные попытки миграции на Apache и прочие телодвижения.
Но на самом деле надо просто настроить перезапуск. Обращаем ваше внимание, что его нужно настроить для каждого пула приложений, если их несколько.
Переходим Пулы приложений – Выбранный пул – Дополнительные параметры
Пролистываем до секции Перезапуск, находим там параметр Моменты точного времени для перезапуска и добавляем туда желаемое время перезапуска пула. Мы выбрали для себя 6 часов утра.
Данный параметр представляет из себя массив, и вы можете добавить несколько моментов времени для перезапуска. Также не забывайте про часовой пояс сервера и часовой пояс клиента.
После чего еще ниже находим опцию Постоянный временной интервал (в минутах), которая и была причиной всех наших безобразий и устанавливаем ей значение в ноль.
Изменив значения не забываем перезапустить пул или веб-сервер полностью (ну или ждем пока он сам в очередной раз перезапустится).
1👍29👀5🔥2❤1🤯1
Что ждет рынок компьютерных комплектующих в 2026 году? Часть 2
В прошлой заметке (https://t.me/interface31/5604) мы рассказали не очень хорошие новости, но ситуация на потребительском рынке продолжает развиваться от плохого к худшему.
Один из крупнейших производителей NAND Samsung подняла в первом квартале 2026 года отпускные цены на твердотельную память более чем на 100%, это, не считая приблизительно 35% повышения цен в 4 квартале 2025 года.
Об аналогичном намерении заявили два других крупнейших игрока этого рынка SK Hynix и SanDisk. Причем речь идет о повышении цен на 100% или близко к тому.
Также происходит перераспределение производственных мощностей в пользу производства RAM, приносящей более высокую прибыль. В 4 квартале прошлого года Samsung сократил выпуск NAND на 5%, а SK Hynix на 10%.
Для понимания экономической подоплеки происходящего можно обратиться к цифрам Samsung, которая показала в последнем квартале прошлого года рост выручки на 22% при практическом удвоении чистой прибыли.
Все это не несет для потребительского рынка ничего хорошего, рост стоимости и уменьшение объемов производства NAND скажется не только на твердотельных накопителях, но и практически на всей электронике, которая сегодня использует NAND как основной тип памяти.
Рост цен неизбежно снизит спрос, что в свою очередь приведет к сокращению производства, увеличению дефицита и новому витку роста цен, теперь уже не только на компьютерном рынке, а на рынке потребительской электроники в целом.
В общем в 2026-27 годах нас ждут трудные времена и многим придется пересмотреть свой подход к приобретению и эксплуатации гаджетов, многие из которых снова начнут кусаться в цене.
Даже если говорить про бум ИИ как некий пузырь, который скоро схлопнется, то это не приведет к массовому падению цен на потребительском рынке. Падать там будет нечему, так как нечего будет продавать.
Снижение цен будет возможно только при повторном насыщении потребительского рынка товарными предложениями, на что может потребоваться продолжительное время, не забываем, что весь объем производства на 2026 уже продан.
Поэтому если вы что-то еще не купили или даже передумали покупать, то самое время еще раз хорошо подумать. Возможно, через некоторое время мы со светлой ностальгией будем вспоминать текущий уровень цен, примерно также, как и «доллар по 30».
В прошлой заметке (https://t.me/interface31/5604) мы рассказали не очень хорошие новости, но ситуация на потребительском рынке продолжает развиваться от плохого к худшему.
Один из крупнейших производителей NAND Samsung подняла в первом квартале 2026 года отпускные цены на твердотельную память более чем на 100%, это, не считая приблизительно 35% повышения цен в 4 квартале 2025 года.
Об аналогичном намерении заявили два других крупнейших игрока этого рынка SK Hynix и SanDisk. Причем речь идет о повышении цен на 100% или близко к тому.
Также происходит перераспределение производственных мощностей в пользу производства RAM, приносящей более высокую прибыль. В 4 квартале прошлого года Samsung сократил выпуск NAND на 5%, а SK Hynix на 10%.
Для понимания экономической подоплеки происходящего можно обратиться к цифрам Samsung, которая показала в последнем квартале прошлого года рост выручки на 22% при практическом удвоении чистой прибыли.
Все это не несет для потребительского рынка ничего хорошего, рост стоимости и уменьшение объемов производства NAND скажется не только на твердотельных накопителях, но и практически на всей электронике, которая сегодня использует NAND как основной тип памяти.
Рост цен неизбежно снизит спрос, что в свою очередь приведет к сокращению производства, увеличению дефицита и новому витку роста цен, теперь уже не только на компьютерном рынке, а на рынке потребительской электроники в целом.
В общем в 2026-27 годах нас ждут трудные времена и многим придется пересмотреть свой подход к приобретению и эксплуатации гаджетов, многие из которых снова начнут кусаться в цене.
Даже если говорить про бум ИИ как некий пузырь, который скоро схлопнется, то это не приведет к массовому падению цен на потребительском рынке. Падать там будет нечему, так как нечего будет продавать.
Снижение цен будет возможно только при повторном насыщении потребительского рынка товарными предложениями, на что может потребоваться продолжительное время, не забываем, что весь объем производства на 2026 уже продан.
Поэтому если вы что-то еще не купили или даже передумали покупать, то самое время еще раз хорошо подумать. Возможно, через некоторое время мы со светлой ностальгией будем вспоминать текущий уровень цен, примерно также, как и «доллар по 30».
😢25🤬7🤡5❤2🥱2
Системы старые, системы устаревшие
В комментариях время от времени поднимается вопрос эксплуатации старых систем и начинают ломаться копья, что мол старое железо вполне еще ого-го и т.д. и т.п.
Поэтому мы решили углубиться в этот вопрос и рассмотреть, какие системы на сегодняшний день хоть и старые, но могут обеспечить комфортную работу, а какие уже безнадежно устарели.
Мы не будем делать упор на обязательную совместимость с Windows 11, но для пользователей данной ОС это тоже немаловажный фактор. Но мы будем исходить из того, что нам нужно обеспечить комфортную работу с современным окружающим миром на базе Windows 10/Linux.
👆 Начнем с аппаратной части. Сегодня для комфортной работы нам нужно, минимум: SATA 600, PCIe 3.0 и USB 3.0, больше – лучше.
👉 По программной части все сложнее, современные системы требуют, как минимум наличия AVX2 и AES-NI. И если последний нужен в основном для криптографии, то AVX2 критически необходим каждому первому.
Данный набор инструкций затрагивает практически все: кодеки, шифрование, сжатие и т.д. и т.п.
Приведем примеры:
▫️SHA-256 - На 40–50% медленнее без AVX2
▫️ Argon2 (хэширование паролей ) - Катастрофически медленно - в 3-5 раз
▫️ Ed25519 (эллиптические кривые ) - Подпись/проверка в 2 раза медленнее
▫️ VP9 – кое как работает до 1080p c крайне высокой нагрузкой на процессор
▫️ AV1 - без AVX2 практически непригоден
▫️ Zstandard - работает через SSE2, но: Скорость сжатия падает на 35-45%,распаковка - на 20-30%
▫️ Brotli- менее зависим от AVX2, но всё равно на 15-25% медленнее
При этом не забываем, что современные сайты во всю используют форматы WebP и AVIF, которые являются производными от VP9/AV1 и будут сильно грузить процессор в современных браузерах.
Тем более что Chrome ≥110 и Firefox ≥115 без поддержки AVX2 просто не запустятся. А если у вас на старой системе стоит более-менее новый браузер, который понимает все эти современные форматы, то расплачиваться будете вы чрезмерной нагрузкой на CPU.
В общем, исходя из сказанного выше минимально комфортной конфигурацией на сегодняшний день является Intel 4-го поколения и AMD Zen Ryzen 1xxx.
Именно там есть поддержка всего нужного в минимальном количестве. Но тут тоже нужно смотреть и думать.
Современные младшие процессоры N100/150 идут вровень с Core i5-45xx, но являются более экономичными, современными и производительными в повседневных задачах.
На наш взгляд, оставаться на платформе 4-7 поколения Intel следует только если она у вас уже есть, и вы можете малой кровью установить туда недорого топ i7 или аналогичный Xeon.
В других случаях надо смотреть или на современные платформы, либо на поколения не ниже восьмого, которое обеспечит совместимость с Windows 11.
Что касается платформы AMD, то там выбрасываем на мусорку все что ниже Zen. Несмотря на то, что последние поколения Excavator поддерживали все нужные функции, удручающая производительность на ядро и ужасающе тепловыделение ставит на них сразу крест.
Из AMD нужно рассматривать Ryzen 1xxx и выше, но первое поколение страдало многими «детскими болезнями» и поэтому фактически следует рассматривать процессоры начиная от Zen+.
Ryzen 1xxx следует рассматривать к покупке только если он существенно более ниже в цене (на 34-40% и более), аналогично следует подходить к Intel поколений от 4-го до 7-го включительно.
В любом случае следует понимать, что технологии не стоят на месте и сегодняшний минимум завтра отправится на свалку истории и к этому надо быть готовым.
В комментариях время от времени поднимается вопрос эксплуатации старых систем и начинают ломаться копья, что мол старое железо вполне еще ого-го и т.д. и т.п.
Поэтому мы решили углубиться в этот вопрос и рассмотреть, какие системы на сегодняшний день хоть и старые, но могут обеспечить комфортную работу, а какие уже безнадежно устарели.
Мы не будем делать упор на обязательную совместимость с Windows 11, но для пользователей данной ОС это тоже немаловажный фактор. Но мы будем исходить из того, что нам нужно обеспечить комфортную работу с современным окружающим миром на базе Windows 10/Linux.
👆 Начнем с аппаратной части. Сегодня для комфортной работы нам нужно, минимум: SATA 600, PCIe 3.0 и USB 3.0, больше – лучше.
👉 По программной части все сложнее, современные системы требуют, как минимум наличия AVX2 и AES-NI. И если последний нужен в основном для криптографии, то AVX2 критически необходим каждому первому.
Данный набор инструкций затрагивает практически все: кодеки, шифрование, сжатие и т.д. и т.п.
Приведем примеры:
▫️SHA-256 - На 40–50% медленнее без AVX2
▫️ Argon2 (хэширование паролей ) - Катастрофически медленно - в 3-5 раз
▫️ Ed25519 (эллиптические кривые ) - Подпись/проверка в 2 раза медленнее
▫️ VP9 – кое как работает до 1080p c крайне высокой нагрузкой на процессор
▫️ AV1 - без AVX2 практически непригоден
▫️ Zstandard - работает через SSE2, но: Скорость сжатия падает на 35-45%,распаковка - на 20-30%
▫️ Brotli- менее зависим от AVX2, но всё равно на 15-25% медленнее
При этом не забываем, что современные сайты во всю используют форматы WebP и AVIF, которые являются производными от VP9/AV1 и будут сильно грузить процессор в современных браузерах.
Тем более что Chrome ≥110 и Firefox ≥115 без поддержки AVX2 просто не запустятся. А если у вас на старой системе стоит более-менее новый браузер, который понимает все эти современные форматы, то расплачиваться будете вы чрезмерной нагрузкой на CPU.
В общем, исходя из сказанного выше минимально комфортной конфигурацией на сегодняшний день является Intel 4-го поколения и AMD Zen Ryzen 1xxx.
Именно там есть поддержка всего нужного в минимальном количестве. Но тут тоже нужно смотреть и думать.
Современные младшие процессоры N100/150 идут вровень с Core i5-45xx, но являются более экономичными, современными и производительными в повседневных задачах.
На наш взгляд, оставаться на платформе 4-7 поколения Intel следует только если она у вас уже есть, и вы можете малой кровью установить туда недорого топ i7 или аналогичный Xeon.
В других случаях надо смотреть или на современные платформы, либо на поколения не ниже восьмого, которое обеспечит совместимость с Windows 11.
Что касается платформы AMD, то там выбрасываем на мусорку все что ниже Zen. Несмотря на то, что последние поколения Excavator поддерживали все нужные функции, удручающая производительность на ядро и ужасающе тепловыделение ставит на них сразу крест.
Из AMD нужно рассматривать Ryzen 1xxx и выше, но первое поколение страдало многими «детскими болезнями» и поэтому фактически следует рассматривать процессоры начиная от Zen+.
Ryzen 1xxx следует рассматривать к покупке только если он существенно более ниже в цене (на 34-40% и более), аналогично следует подходить к Intel поколений от 4-го до 7-го включительно.
В любом случае следует понимать, что технологии не стоят на месте и сегодняшний минимум завтра отправится на свалку истории и к этому надо быть готовым.
1👍29🔥15🤔9❤7🤝2
Насколько нужен AVX2, практика
Небольшое исследование на предмет нужности и полезности инструкций AVX2. Чтобы оценить их влияние мы взяли одну из наших виртуалок, выключили в ней инструкции AVX и реализовали наиболее распространенный сценарий – просмотр видео на YouTube в качестве 1080HD.
Инструкции AVX отключены, загрузка выделенных виртуалке 4 ядер Ryzen 9 5900X составляет 30-40%.
Инструкции AVX включены, тот же самый ролик в том же самом качестве, нагрузка на процессор в районе 10%.
Результат очевиден, на декодировании видео AVX2 дает выигрыш в 3,5 раза! И это сам по себе мощный современный процессор, а что будет с тем же Intel 3-го поколения даже думать не хочется.
При этом напомним, что AVX2 – это не только видео, но и криптография, с которой вы сталкиваетесь на каждом шагу в интернет, сжатие – т.е. полный набор повседневных задач.
Нет, без AVX2 жить конечно можно, но только такую жизнь сложно назвать комфортной, потому что даже элементарные действия будут вызывать серьезную нагрузку на процессор.
Небольшое исследование на предмет нужности и полезности инструкций AVX2. Чтобы оценить их влияние мы взяли одну из наших виртуалок, выключили в ней инструкции AVX и реализовали наиболее распространенный сценарий – просмотр видео на YouTube в качестве 1080HD.
Инструкции AVX отключены, загрузка выделенных виртуалке 4 ядер Ryzen 9 5900X составляет 30-40%.
Инструкции AVX включены, тот же самый ролик в том же самом качестве, нагрузка на процессор в районе 10%.
Результат очевиден, на декодировании видео AVX2 дает выигрыш в 3,5 раза! И это сам по себе мощный современный процессор, а что будет с тем же Intel 3-го поколения даже думать не хочется.
При этом напомним, что AVX2 – это не только видео, но и криптография, с которой вы сталкиваетесь на каждом шагу в интернет, сжатие – т.е. полный набор повседневных задач.
Нет, без AVX2 жить конечно можно, но только такую жизнь сложно назвать комфортной, потому что даже элементарные действия будут вызывать серьезную нагрузку на процессор.
👍36🥱4🤣2🤝1
Действие JUMP и собственные цепочки в iptables и брандмауэре Mikrotik
Про то, как пакеты бегают по цепочкам брандмауэра, мы рассказывать не будем, это все знают, а если не знают, то перед тем, как читать эту заметку им следует ознакомиться с базовыми принципами работы iptables.
Сегодня мы поговорим о другом, а именно об оптимизации правил брандмауэра и снижении нагрузки. Особенно это актуально для недорогих роутеров, таких как Mikrotik, но не будет лишним и на любых других системах.
Как мы помним любой пакет попадая в цепочку iptables (а в Mikrotik тот же самый iptables) начинает движение по правилам последовательно, до первого совпадения критериев. Затем, если правило терминальное, он прекращает движение по цепочке и переходит в следующую.
А теперь представьте, что у вас в цепочке несколько десятков правил и пакет попадает под критерии условно 30-го. Перед этим он впустую пройдет предыдущие 29 попадая под все проверки и вызывая дополнительную нагрузку.
И чем больше у вас в цепочке правил, тем более высокой будет нагрузка, особенно если в правилах есть «дорогие» критерии.
Можно, конечно, оптимизировать расположение правил, чтобы дорогие проверки стояли после дешевых, но не всегда это возможно, а также не решает задачи холостого срабатывания цепочек.
И вот здесь нам на помощь придут цепочки собственные и действие JUMP, которое поможет нам перейти в эти цепочки.
А дальше довольно просто, прежде всего определяем группы правил, которые можно объединить по какому-либо общему критерию и выносим их в отдельную цепочку, а в основной цепочке делаем JUMP по срабатыванию на этот общий критерий.
Например, если из 30 правил мы выделим 5 групп по 5 правил, то у нас в основной цепочке их останется только 10 и пять из них будут гораздо более простыми. Таким образом пакет пройдет брандмауэр гораздо быстрее и с меньшей нагрузкой на оборудование.
После чего следует аналогичным образом вынести и тяжелые правила, разделив их на проверку по простым критериям, на основании которой будет переход в отдельную цепочку, где уже будем дополнительно проводить «дорогие» проверки.
С одной стороны, у нас вместо одного правила получается два, но по факту мы оказываемся в выигрыше, так как большая часть пакетов будет проходить проверку только по «дешевым» критериям, не вызывая проверку «дорогих».
Также имеет смысл выносить в отдельные цепочки логические группы правил, объединенные общим назначением, что не только уменьшит нагрузку, но и позволит более легко читать сложные конфигурации брандмауэра.
Количество пользовательских цепочек не ограничено, и работа с ними ничем не отличается от стандартных, при срабатывании правила пакет прекращает движение по цепочке и возвращается к месту вызова. Туда же он вернется если не сработало ни одно правило.
Вызывать собственную цепочку можно из любого места, даже из другой собственной цепочки. Это позволяет также упростить конфигурацию брандмауэра за счет повторного использования наборов правил для разных цепочек.
Практические примеры использования собственных цепочек и JUMP мы рассмотрим в следующей заметке.
Про то, как пакеты бегают по цепочкам брандмауэра, мы рассказывать не будем, это все знают, а если не знают, то перед тем, как читать эту заметку им следует ознакомиться с базовыми принципами работы iptables.
Сегодня мы поговорим о другом, а именно об оптимизации правил брандмауэра и снижении нагрузки. Особенно это актуально для недорогих роутеров, таких как Mikrotik, но не будет лишним и на любых других системах.
Как мы помним любой пакет попадая в цепочку iptables (а в Mikrotik тот же самый iptables) начинает движение по правилам последовательно, до первого совпадения критериев. Затем, если правило терминальное, он прекращает движение по цепочке и переходит в следующую.
А теперь представьте, что у вас в цепочке несколько десятков правил и пакет попадает под критерии условно 30-го. Перед этим он впустую пройдет предыдущие 29 попадая под все проверки и вызывая дополнительную нагрузку.
И чем больше у вас в цепочке правил, тем более высокой будет нагрузка, особенно если в правилах есть «дорогие» критерии.
Можно, конечно, оптимизировать расположение правил, чтобы дорогие проверки стояли после дешевых, но не всегда это возможно, а также не решает задачи холостого срабатывания цепочек.
И вот здесь нам на помощь придут цепочки собственные и действие JUMP, которое поможет нам перейти в эти цепочки.
А дальше довольно просто, прежде всего определяем группы правил, которые можно объединить по какому-либо общему критерию и выносим их в отдельную цепочку, а в основной цепочке делаем JUMP по срабатыванию на этот общий критерий.
Например, если из 30 правил мы выделим 5 групп по 5 правил, то у нас в основной цепочке их останется только 10 и пять из них будут гораздо более простыми. Таким образом пакет пройдет брандмауэр гораздо быстрее и с меньшей нагрузкой на оборудование.
После чего следует аналогичным образом вынести и тяжелые правила, разделив их на проверку по простым критериям, на основании которой будет переход в отдельную цепочку, где уже будем дополнительно проводить «дорогие» проверки.
С одной стороны, у нас вместо одного правила получается два, но по факту мы оказываемся в выигрыше, так как большая часть пакетов будет проходить проверку только по «дешевым» критериям, не вызывая проверку «дорогих».
Также имеет смысл выносить в отдельные цепочки логические группы правил, объединенные общим назначением, что не только уменьшит нагрузку, но и позволит более легко читать сложные конфигурации брандмауэра.
Количество пользовательских цепочек не ограничено, и работа с ними ничем не отличается от стандартных, при срабатывании правила пакет прекращает движение по цепочке и возвращается к месту вызова. Туда же он вернется если не сработало ни одно правило.
Вызывать собственную цепочку можно из любого места, даже из другой собственной цепочки. Это позволяет также упростить конфигурацию брандмауэра за счет повторного использования наборов правил для разных цепочек.
Практические примеры использования собственных цепочек и JUMP мы рассмотрим в следующей заметке.
❤8👌5👍4😱3🥱1
Cобственные цепочки в iptables и брандмауэре Mikrotik. Практика.
В прошлой заметке говорили от том, для чего нужны собственные цепочки в брандмауэре, а сегодня посмотрим, как с ними работать на практике. Начнем с iptables.
Мы все привыкли к правилам вида:
И не задумываемся что означает -j перед действием, а обозначает он -–jump – переход. Это стандартное действие брандмауэра и переход может быть выполнен как на встроенную цель – ACCEPT, DROP и т.д., так и на пользовательскую цепочку.
Однако далеко не все коллеги, особенно начинающие знают о такой тонкости и поэтому для переходов мы советуем использовать полный синтаксис и писать -–jump, а не -j.
А мы перейдем к практической цели, допустим мы хотим выборочно фильтровать ICMP трафик, поэтому делать это в основной цепочке нет никакого смысла, и мы создадим свою собственную.
Первичный критерий отбора прост – весь ICMP трафик заворачиваем в собственную цепочку:
Затем добавляем правила в нашу новую цепочку, размещать мы их можем где хотим, имеет значение только порядок следования правил в цепочке. Это позволяет выделять такие блоки отдельно и тем самым увеличивать читабельность правил.
И уже в цепочке мы фильтруем правила по собственному усмотрению, в нашем примере мы разрешили эхо-запрос (тип 8, код 0) и эхо-ответ (тип 0, код 0).
Для Mikrotik все будет тоже самое, только с учетом синтаксиса ROS. Сначала заворачиваем весь интересующий нас трафик командой в свою цепочку:
А затем фильтруем его:
Обратите внимание, что последнее действие DROP мы выполняем без всяких критериев, потому как никакого другого трафика в нашей цепочке быть не может.
В прошлой заметке говорили от том, для чего нужны собственные цепочки в брандмауэре, а сегодня посмотрим, как с ними работать на практике. Начнем с iptables.
Мы все привыкли к правилам вида:
iptables -A INPUT -i ens33 -s 192.168.0.0/24 -j ACCEPT
И не задумываемся что означает -j перед действием, а обозначает он -–jump – переход. Это стандартное действие брандмауэра и переход может быть выполнен как на встроенную цель – ACCEPT, DROP и т.д., так и на пользовательскую цепочку.
Однако далеко не все коллеги, особенно начинающие знают о такой тонкости и поэтому для переходов мы советуем использовать полный синтаксис и писать -–jump, а не -j.
А мы перейдем к практической цели, допустим мы хотим выборочно фильтровать ICMP трафик, поэтому делать это в основной цепочке нет никакого смысла, и мы создадим свою собственную.
Первичный критерий отбора прост – весь ICMP трафик заворачиваем в собственную цепочку:
iptables -A INPUT -p icmp -–jump ICMP
Затем добавляем правила в нашу новую цепочку, размещать мы их можем где хотим, имеет значение только порядок следования правил в цепочке. Это позволяет выделять такие блоки отдельно и тем самым увеличивать читабельность правил.
iptables -A ICMP -p icmp --icmp-type 0/0 -j ACCEPT
iptables -A ICMP -p icmp --icmp-type 8/0 -j ACCEPT
…
iptables -A ICMP -j DROP
И уже в цепочке мы фильтруем правила по собственному усмотрению, в нашем примере мы разрешили эхо-запрос (тип 8, код 0) и эхо-ответ (тип 0, код 0).
Для Mikrotik все будет тоже самое, только с учетом синтаксиса ROS. Сначала заворачиваем весь интересующий нас трафик командой в свою цепочку:
add action=jump chain=input jump-target=ICMP protocol=icmp
А затем фильтруем его:
add action=accept chain=ICMP icmp-options=0:0 protocol=icmp
add action=accept chain=ICMP icmp-options=8:0 protocol=icmp
…
add action=drop chain=ICMP
Обратите внимание, что последнее действие DROP мы выполняем без всяких критериев, потому как никакого другого трафика в нашей цепочке быть не может.
👍22❤1😱1🤮1
Клиент-серверная 1С. Структура
Вопросы и отзывы показывают, что многие коллеги слабо представляют себе устройство клиент-серверной 1С и взаимодействие между ее компонентами.
Начнем с сервера, он так и называется Сервер 1С:Предприятие и может работать как под Windows, так и в Linux. Рабочая инсталляция сервера называется Кластер серверов 1С, даже если экземпляр сервера один.
Впоследствии, для увеличения производительности, мы можем добавлять в кластер дополнительные рабочие сервера, и менеджер кластера будет распределять между ними нагрузку.
Также мы можем выносить на отдельные рабочие сервера дополнительные функции, например, сервер лицензирования.
Вся информация, с которой работает пользователь, а также код конфигурации (прикладного решения) хранятся в СУБД, в качестве которых чаще всего используется MS SQL или PostgreSQL.
Сразу хочется обратить внимание на то, что с СУБД взаимодействует исключительно сервер, клиенты доступа к серверу СУБД не имеют и напрямую в БД не обращаются. Более того, это прямо запрещено лицензионным соглашением 1С.
Вся информация из одной информационной базы 1С, включая конфигурацию, загруженные в нее отчеты, обработки и расширения хранится в одной базе данных СУБД. Т.е. вы можете выполнять полноценное копирование средствами СУБД и затем восстанавливать ИБ подобным образом.
Однако если вы лицензируете СУБД по количеству пользователей, то вам потребуется количество лицензий по числу реальных клиентских подключений.
Теперь перейдем к клиентам. Толстый клиент является устаревшим и современными конфигурациями не используется.
Его неприятной особенностью является то, что он все данные обрабатывает самостоятельно и сервер в этом случае будет для него просто посредником, который извлекает данные из СУБД, передает их клиенту и получив назад снова помещает в БД.
Для работы в таком режиме требуются широкие каналы и мощная рабочая станция, на которой запущен толстый клиент.
Сейчас в режиме толстого клиента работает только конфигуратор, но в эксплуатации еще могут быть устаревшие конфигурации на обычных формах, которые не умеют работать в ином режиме.
Основной вариант работы для современных конфигураций – это тонкий клиент. В этом случае задачи по извлечению и обработке данных ложатся на сервер, а клиент принимает только ввод пользователя и показывает ему результаты вычислений.
В дополнение к этому тонкий клиент самостоятельно обрабатывает введенные данные и выполняет простейшие вычисления, ради которых нет смысла обращаться к серверу. Например, пользователь изменил колонку цена, после чего тонкий клиент сам пересчитает колонку сумма.
Но любые действия по получению данных из СУБД и помещению их туда выполняет сервер, равно как и все основные тяжелые вычисления.
Благодаря этому тонкий клиент отлично работает даже на медленных каналах, включая мобильный интернет.
Он может подключаться к кластеру серверов как непосредственно, так и через веб-сервер. В серверном режиме веб-сервер просто проксирует запросы от тонкого клиента к кластеру серверов и непосредственных вычислений не производит.
Такой режим удобен для публикации баз наружу, в этом случае достаточно одного порта, который можно защитить SSL сертификатом и дополнительной парольной защитой.
Ну и наконец веб-клиент, работает в браузере и, по сути, мало чем отличается от тонкого клиента. Но в этом случае клиентом кластера серверов становится модуль веб-сервера и вся клиентская нагрузка ложиться на него, но она как правило невелика и особых проблем не составляет.
Единственной проблемой может стать выделение оперативной памяти, потому что после отключения веб-клиента его сеанс, а следовательно, и выделенная ему память, сохраняются в течении 20 минут.
Также веб-клиенту присущ ряд ограничений, а также у него своя схема лицензирования, поэтому использовать веб-клиент следует только тогда, когда использовать тонкий клиент невозможно.
Поэтому, проектируя соверменные схемы работы с 1С всегда исходите из использования тонкого клиента.
Вопросы и отзывы показывают, что многие коллеги слабо представляют себе устройство клиент-серверной 1С и взаимодействие между ее компонентами.
Начнем с сервера, он так и называется Сервер 1С:Предприятие и может работать как под Windows, так и в Linux. Рабочая инсталляция сервера называется Кластер серверов 1С, даже если экземпляр сервера один.
Впоследствии, для увеличения производительности, мы можем добавлять в кластер дополнительные рабочие сервера, и менеджер кластера будет распределять между ними нагрузку.
Также мы можем выносить на отдельные рабочие сервера дополнительные функции, например, сервер лицензирования.
Вся информация, с которой работает пользователь, а также код конфигурации (прикладного решения) хранятся в СУБД, в качестве которых чаще всего используется MS SQL или PostgreSQL.
Сразу хочется обратить внимание на то, что с СУБД взаимодействует исключительно сервер, клиенты доступа к серверу СУБД не имеют и напрямую в БД не обращаются. Более того, это прямо запрещено лицензионным соглашением 1С.
Вся информация из одной информационной базы 1С, включая конфигурацию, загруженные в нее отчеты, обработки и расширения хранится в одной базе данных СУБД. Т.е. вы можете выполнять полноценное копирование средствами СУБД и затем восстанавливать ИБ подобным образом.
Однако если вы лицензируете СУБД по количеству пользователей, то вам потребуется количество лицензий по числу реальных клиентских подключений.
Теперь перейдем к клиентам. Толстый клиент является устаревшим и современными конфигурациями не используется.
Его неприятной особенностью является то, что он все данные обрабатывает самостоятельно и сервер в этом случае будет для него просто посредником, который извлекает данные из СУБД, передает их клиенту и получив назад снова помещает в БД.
Для работы в таком режиме требуются широкие каналы и мощная рабочая станция, на которой запущен толстый клиент.
Сейчас в режиме толстого клиента работает только конфигуратор, но в эксплуатации еще могут быть устаревшие конфигурации на обычных формах, которые не умеют работать в ином режиме.
Основной вариант работы для современных конфигураций – это тонкий клиент. В этом случае задачи по извлечению и обработке данных ложатся на сервер, а клиент принимает только ввод пользователя и показывает ему результаты вычислений.
В дополнение к этому тонкий клиент самостоятельно обрабатывает введенные данные и выполняет простейшие вычисления, ради которых нет смысла обращаться к серверу. Например, пользователь изменил колонку цена, после чего тонкий клиент сам пересчитает колонку сумма.
Но любые действия по получению данных из СУБД и помещению их туда выполняет сервер, равно как и все основные тяжелые вычисления.
Благодаря этому тонкий клиент отлично работает даже на медленных каналах, включая мобильный интернет.
Он может подключаться к кластеру серверов как непосредственно, так и через веб-сервер. В серверном режиме веб-сервер просто проксирует запросы от тонкого клиента к кластеру серверов и непосредственных вычислений не производит.
Такой режим удобен для публикации баз наружу, в этом случае достаточно одного порта, который можно защитить SSL сертификатом и дополнительной парольной защитой.
Ну и наконец веб-клиент, работает в браузере и, по сути, мало чем отличается от тонкого клиента. Но в этом случае клиентом кластера серверов становится модуль веб-сервера и вся клиентская нагрузка ложиться на него, но она как правило невелика и особых проблем не составляет.
Единственной проблемой может стать выделение оперативной памяти, потому что после отключения веб-клиента его сеанс, а следовательно, и выделенная ему память, сохраняются в течении 20 минут.
Также веб-клиенту присущ ряд ограничений, а также у него своя схема лицензирования, поэтому использовать веб-клиент следует только тогда, когда использовать тонкий клиент невозможно.
Поэтому, проектируя соверменные схемы работы с 1С всегда исходите из использования тонкого клиента.
👍32❤8🥱2🤝1
Первый взгляд на Ninkear Мини-ПК Mbox11
Системы на базе Intel N100/150 пользуются заслуженной популярностью у пользователей. Этот процессор, точнее SoC содержит 4 энергоэффективных ядра последних поколений и обеспечивает производительность на уровне Core i5 4-го поколения при тепловом пакете до 25 Вт.
Intel N150 лежащий в основе Mbox11 имеет базовую частоту 0,8 ГГц с бустом до 3,6 ГГц и поддерживает до 16 ГБ DDR4 3200 или DDR5 4800 в одноканальном режиме.
Данные системы отлично закрывают нишу тонких клиентов, офисных ПК класса «печатная машинка», домашних серверов и даже домашних лабораторий. На N100/150 вполне нормально чувствует себя Proxmox, а производительности процессора хватает для задач дома или малого офиса.
В данном классе мы обычно приобретали устройства от DEXP или iRU, Irbis. Все это доступно в наших сетевых магазинах, продается с гарантией и основано на одной и той же аппаратной платформе.
А сейчас вот для одного заказчика остановились на Ninkear Mbox11, причина простая – надо было еще вчера, а все сетевые магазины раньше, чем через неделю не доставляли. Поэтому покупку совершили в официальном магазине бренда на OZON и получили мини-ПК уже через день.
Поменяли ли мы шило на мыло? Нет, что тут, что там производство одно – Китай и комплектующие везде плюс-минус одинаковы. А что касается гарантии, но на OZON сейчас даже проще, вы можете просто сдать товар без объяснений в первые 14 дней.
Мини-ПК небольшой, 100*100*33 мм, в пластиковом серо-серебристом корпусе. На передней панели два разъема USB 3, разъем аудио и кнопка включения. На задней RJ-45, HDMI, Display Port и 2 USB 2.
Разъемом немного, но в целом достаточно. Плюс-минус у всех одноклассников подобный набор. И в целом в общем ряду Mbox11 ничем таким не выделяется.
На борту Windows 11 Pro, лицензия зашита в BIOS, активируется и работает нормально. При первом запуске приготовьтесь качать и устанавливать обновления, что займет примерно около часа.
Из беспроводных коммуникаций имеется Wi-Fi 5 ( 802.11ac) и Bluetooth 5.0, последний позволяет подключить клавиатуру, мышку, колонки/наушники и сэкономить USB разъемы.
Лично мы железку не разбирали, поэтому фото будут из сети. Внутри классика жанра – китайские память и SATA SSD. Память – планка от Kinsotin 16 ГБ DDR4 2700, диск – неизвестный SATA SSD 512 ГБ на базе бюджетного SM2259XT2.
Все приблизительно тоже самое вы найдете в любой аналогичной коробочке. Так что тут ни удивляться, ни расстраиваться не стоит. Память и диск вы можете заменить.
А теперь тесты. Что нам понравилось – это система охлаждения, достаточно массивный радиатор и крупный вентилятор, который практически неслышно. Шуметь он начинает где-то ближе к 70 градусам, но шум мягкий, ненапрягающий.
Следует отметить, что DEXP или iRU обычно имеют в составе системы охлаждения турбину и шумят под нагрузкой гораздо более сильнее.
Тепловой пакет процессора в BIOS ограничен на уровне 15Вт и частот выше 2,9 ГГц вы не увидите, но поэтому процессор даже под сильной нагрузкой не выходит за пределы 77 градусов и вполне комфортен по уровню нагрева и шума.
В состоянии покоя температура держится на уровне 40-45 градусов, что для данного чипа нормально.
Тепловой пакет нельзя изменить, но можно просто отключить в BIOS лимит мощности. Также можно заменить память на более быструю – 3200 или попробовать разогнать эту, по отзывам у многих неплохо получается.
Также есть поддержка NVMe, при наличии нужного диска можете поставить его вместо штатного, но по большому счету все это не приведет к какому-либо ощутимому невооруженным глазом эффекту.
В текущей конфигурации система достаточно сбалансирована, а хорошее охлаждение позволяет использовать его в качестве домашнего сервера даже в жилых помещениях, где уровень шума бывает критичным.
Поэтому данный китаец неплох, можно брать, не хуже, а в чем-то даже лучше своих собратьев от отечественных брендов.
Системы на базе Intel N100/150 пользуются заслуженной популярностью у пользователей. Этот процессор, точнее SoC содержит 4 энергоэффективных ядра последних поколений и обеспечивает производительность на уровне Core i5 4-го поколения при тепловом пакете до 25 Вт.
Intel N150 лежащий в основе Mbox11 имеет базовую частоту 0,8 ГГц с бустом до 3,6 ГГц и поддерживает до 16 ГБ DDR4 3200 или DDR5 4800 в одноканальном режиме.
Данные системы отлично закрывают нишу тонких клиентов, офисных ПК класса «печатная машинка», домашних серверов и даже домашних лабораторий. На N100/150 вполне нормально чувствует себя Proxmox, а производительности процессора хватает для задач дома или малого офиса.
В данном классе мы обычно приобретали устройства от DEXP или iRU, Irbis. Все это доступно в наших сетевых магазинах, продается с гарантией и основано на одной и той же аппаратной платформе.
А сейчас вот для одного заказчика остановились на Ninkear Mbox11, причина простая – надо было еще вчера, а все сетевые магазины раньше, чем через неделю не доставляли. Поэтому покупку совершили в официальном магазине бренда на OZON и получили мини-ПК уже через день.
Поменяли ли мы шило на мыло? Нет, что тут, что там производство одно – Китай и комплектующие везде плюс-минус одинаковы. А что касается гарантии, но на OZON сейчас даже проще, вы можете просто сдать товар без объяснений в первые 14 дней.
Мини-ПК небольшой, 100*100*33 мм, в пластиковом серо-серебристом корпусе. На передней панели два разъема USB 3, разъем аудио и кнопка включения. На задней RJ-45, HDMI, Display Port и 2 USB 2.
Разъемом немного, но в целом достаточно. Плюс-минус у всех одноклассников подобный набор. И в целом в общем ряду Mbox11 ничем таким не выделяется.
На борту Windows 11 Pro, лицензия зашита в BIOS, активируется и работает нормально. При первом запуске приготовьтесь качать и устанавливать обновления, что займет примерно около часа.
Из беспроводных коммуникаций имеется Wi-Fi 5 ( 802.11ac) и Bluetooth 5.0, последний позволяет подключить клавиатуру, мышку, колонки/наушники и сэкономить USB разъемы.
Лично мы железку не разбирали, поэтому фото будут из сети. Внутри классика жанра – китайские память и SATA SSD. Память – планка от Kinsotin 16 ГБ DDR4 2700, диск – неизвестный SATA SSD 512 ГБ на базе бюджетного SM2259XT2.
Все приблизительно тоже самое вы найдете в любой аналогичной коробочке. Так что тут ни удивляться, ни расстраиваться не стоит. Память и диск вы можете заменить.
А теперь тесты. Что нам понравилось – это система охлаждения, достаточно массивный радиатор и крупный вентилятор, который практически неслышно. Шуметь он начинает где-то ближе к 70 градусам, но шум мягкий, ненапрягающий.
Следует отметить, что DEXP или iRU обычно имеют в составе системы охлаждения турбину и шумят под нагрузкой гораздо более сильнее.
Тепловой пакет процессора в BIOS ограничен на уровне 15Вт и частот выше 2,9 ГГц вы не увидите, но поэтому процессор даже под сильной нагрузкой не выходит за пределы 77 градусов и вполне комфортен по уровню нагрева и шума.
В состоянии покоя температура держится на уровне 40-45 градусов, что для данного чипа нормально.
Тепловой пакет нельзя изменить, но можно просто отключить в BIOS лимит мощности. Также можно заменить память на более быструю – 3200 или попробовать разогнать эту, по отзывам у многих неплохо получается.
Также есть поддержка NVMe, при наличии нужного диска можете поставить его вместо штатного, но по большому счету все это не приведет к какому-либо ощутимому невооруженным глазом эффекту.
В текущей конфигурации система достаточно сбалансирована, а хорошее охлаждение позволяет использовать его в качестве домашнего сервера даже в жилых помещениях, где уровень шума бывает критичным.
Поэтому данный китаец неплох, можно брать, не хуже, а в чем-то даже лучше своих собратьев от отечественных брендов.
👍27❤4🤮2
This media is not supported in your browser
VIEW IN TELEGRAM
И еще, тоже из жизни...
Региональный сервис, суровый и беспощадный. И еще деньги за это берут. 🙈🙈🙈
Региональный сервис, суровый и беспощадный. И еще деньги за это берут. 🙈🙈🙈
👀5👍4
Про «барыг»
Всплывала на неделе эта тема, про «барыг» на компьютерном рынке, которые гнут непомерные цены и, наверное, сказочно обогащаются на бедных-несчастных покупателях.
Сегодня днем было время, и я покопался в архивах, чтобы вспомнить как это было, потому как от продаж компьютерных комплектующих я сейчас достаточно далек.
Когда я пришел в эту отрасль в 2003 году, то на рынке нашего областного центра с разной степенью успешности работали пять крупных по городским меркам фирм и еще больше мелких.
Интернет в те годы был в зачаточном состоянии, как и интернет-торговля, про федеральные сети никто особо не слышал, но рынок уже тогда не блистал прибыльностью.
Средний процент наценки в те годы был всего 10%, для сравнения – средняя наценка в продуктовой рознице 35%. На какие-то позиции больше, на какие-то меньше, но в среднем было именно 10%, на это и ориентировались.
В те годы как раз был компьютерный бум, цены на комплектующие снизились до доступного уровня и компьютер перестал быть роскошью. Возили и собирали мы много, но преимущественно по нижней ценовой планке. Т.е. жили сугубо с оборота.
Потом я вырос и ушел в самостоятельное плавание по волнам предпринимательской деятельности. Кроме аутсорса, который уже тогда кормил, пробовал держать свой сервисный центр и параллельно приторговывать компьютерами.
И вот у меня в руках старые документы, прайс поставщика от 30 января 2008 года с курсом доллара в 25,6 рублей и финансовые результаты за 2007 год. Именно тогда от продаж железа мы отказались.
За счет чего жила тогда маленькая фирма по продаже комплектующих? За счет цены и сервиса. Цена немного ниже или такая же как у основных игроков на рынке, но индивидуальный подход и всякие подобные плюшки, вроде привоза ПК домой, установки и подключения с кратким ликбезом.
Оно уже само по себе затратное мероприятие, но по-другому было не выжить.
Местный поставщик отдавал нам товар с наценкой в 4%, поэтому чтобы держать привлекательный уровень цен мы не должны были сильно отличаться от рынка, т.е. средняя наценка у нас получалась 5,7%.
Для понимания проведем, как говорилось в те годы, небольшой финансовый стриптиз. За 4 квартал 2007 года оборот по железу составил 897 тыс. руб. Ну как-бы неплохо, почти миллион.
Но, при наценке в 5,7% выручка составила всего 51 тыс. руб. или 17 тыс. руб. в месяц, а после уплаты налогов осталось всего 14,5 тыс. руб. Это на уровне средней зарплаты по Черноземью в те годы, а за аренду я платил тогда 15 тыс. руб. + коммуналка.
И это без учета накладных расходов: аренды, зарплаты, рекламы и т.д. и т.п. Маржинальность уже на этом уровне составляла 4,85%, а реальная – еще ниже. При том, что маржинальность менее 10% считается крайне низкой.
Плюс любая нестандартная ситуация, брак или гарантия, выбивала этот бизнес из финансового седла. Ну что такое в те времена 14 тыс. руб.? Ниже некоторые закупочные цены:
▫️19" MONITOR BenQ E900T <Silver-Black> (LCD, 1280x1024, +DVI) - 6480.9
▫️CPU INTEL Core 2 Duo E8400 (3,0GHz) LGA775 OEM – 5300
▫️M/B ASUSTeK P5G-MX (RTL) Socket775 <i945GC>> - 3475.93
А цена недорогого компьютера в сборе стартовала от 20 тыс. руб. в закупке.
Если пересчитать суммы на современный лад, то получим оборот около 3,5 млн. и выручку около 150 тыс. Офигенный бизнес? И это не просто купи-продай, тут надо привезти, собрать, настроить. Обеспечить постпродажный сервис, гарантию и т.д. и т.п.
Ну и нафига все это нужно при таком смешном выхлопе? Да нафиг не нужно, сказали мы и это направление закрыли. А потом стало интересней, пришли федеральные сети в виде DNS, компьютеры начали продавать магазины бытовой техники типа Эльдорадо и М-Видео.
После чего уже крупные местные игроки были вынуждены снижать наценку до 5-7% чтобы хоть как-то оставаться на плаву, но это уже не бизнес, денег там нет.
Как итог – местных фирм теперь можно посчитать по пальцам, а те, которые есть сидят в основном на пригретых местах, типа госконтрактов и т.п. и в розничном покупателе сильно не заинтересованы.
Как и нет новых желающих войти в этот рынок.
Всплывала на неделе эта тема, про «барыг» на компьютерном рынке, которые гнут непомерные цены и, наверное, сказочно обогащаются на бедных-несчастных покупателях.
Сегодня днем было время, и я покопался в архивах, чтобы вспомнить как это было, потому как от продаж компьютерных комплектующих я сейчас достаточно далек.
Когда я пришел в эту отрасль в 2003 году, то на рынке нашего областного центра с разной степенью успешности работали пять крупных по городским меркам фирм и еще больше мелких.
Интернет в те годы был в зачаточном состоянии, как и интернет-торговля, про федеральные сети никто особо не слышал, но рынок уже тогда не блистал прибыльностью.
Средний процент наценки в те годы был всего 10%, для сравнения – средняя наценка в продуктовой рознице 35%. На какие-то позиции больше, на какие-то меньше, но в среднем было именно 10%, на это и ориентировались.
В те годы как раз был компьютерный бум, цены на комплектующие снизились до доступного уровня и компьютер перестал быть роскошью. Возили и собирали мы много, но преимущественно по нижней ценовой планке. Т.е. жили сугубо с оборота.
Потом я вырос и ушел в самостоятельное плавание по волнам предпринимательской деятельности. Кроме аутсорса, который уже тогда кормил, пробовал держать свой сервисный центр и параллельно приторговывать компьютерами.
И вот у меня в руках старые документы, прайс поставщика от 30 января 2008 года с курсом доллара в 25,6 рублей и финансовые результаты за 2007 год. Именно тогда от продаж железа мы отказались.
За счет чего жила тогда маленькая фирма по продаже комплектующих? За счет цены и сервиса. Цена немного ниже или такая же как у основных игроков на рынке, но индивидуальный подход и всякие подобные плюшки, вроде привоза ПК домой, установки и подключения с кратким ликбезом.
Оно уже само по себе затратное мероприятие, но по-другому было не выжить.
Местный поставщик отдавал нам товар с наценкой в 4%, поэтому чтобы держать привлекательный уровень цен мы не должны были сильно отличаться от рынка, т.е. средняя наценка у нас получалась 5,7%.
Для понимания проведем, как говорилось в те годы, небольшой финансовый стриптиз. За 4 квартал 2007 года оборот по железу составил 897 тыс. руб. Ну как-бы неплохо, почти миллион.
Но, при наценке в 5,7% выручка составила всего 51 тыс. руб. или 17 тыс. руб. в месяц, а после уплаты налогов осталось всего 14,5 тыс. руб. Это на уровне средней зарплаты по Черноземью в те годы, а за аренду я платил тогда 15 тыс. руб. + коммуналка.
И это без учета накладных расходов: аренды, зарплаты, рекламы и т.д. и т.п. Маржинальность уже на этом уровне составляла 4,85%, а реальная – еще ниже. При том, что маржинальность менее 10% считается крайне низкой.
Плюс любая нестандартная ситуация, брак или гарантия, выбивала этот бизнес из финансового седла. Ну что такое в те времена 14 тыс. руб.? Ниже некоторые закупочные цены:
▫️19" MONITOR BenQ E900T <Silver-Black> (LCD, 1280x1024, +DVI) - 6480.9
▫️CPU INTEL Core 2 Duo E8400 (3,0GHz) LGA775 OEM – 5300
▫️M/B ASUSTeK P5G-MX (RTL) Socket775 <i945GC>> - 3475.93
А цена недорогого компьютера в сборе стартовала от 20 тыс. руб. в закупке.
Если пересчитать суммы на современный лад, то получим оборот около 3,5 млн. и выручку около 150 тыс. Офигенный бизнес? И это не просто купи-продай, тут надо привезти, собрать, настроить. Обеспечить постпродажный сервис, гарантию и т.д. и т.п.
Ну и нафига все это нужно при таком смешном выхлопе? Да нафиг не нужно, сказали мы и это направление закрыли. А потом стало интересней, пришли федеральные сети в виде DNS, компьютеры начали продавать магазины бытовой техники типа Эльдорадо и М-Видео.
После чего уже крупные местные игроки были вынуждены снижать наценку до 5-7% чтобы хоть как-то оставаться на плаву, но это уже не бизнес, денег там нет.
Как итог – местных фирм теперь можно посчитать по пальцам, а те, которые есть сидят в основном на пригретых местах, типа госконтрактов и т.п. и в розничном покупателе сильно не заинтересованы.
Как и нет новых желающих войти в этот рынок.
👍32💯10❤3👀3🤮1