mayton2019

До того как автор начнет что-то повышать. Пускай послушает мою мысль. Между 3.33 и 3.6 разница порядка 8%
Общий индекс производительности системы зависит не только от процессора но вообще от совокупной работы всех частей (реакция памяти и скорость кешей L1/L2/L3). Если просто повышать частоту CPU но при этом не менять ничего остального то эффект - нивелируется. Ожидаемого прироста 8% не будет. Будет меньше.

Даже если гипотетически предположить что автор поднял частоту до 5Ghz то и в этом случае удвоения перформанса не будет.

Вобщем послушайте старого программиста на C++ и прочих ассемблерах. Не тратье своё время на фигню. Ваша игра или рендеринг 3Д графики особой разницы не почувствуют. Взамен вы получите потенциальные проблемы. Ведь производитель не собирался делать нестандартный режим номинальным. В этом был свой смысл.

Скорее всего убунта была не выключена а запаркована в хибернейт. В этом случае большинство устройств тоже паркуются.

Проверь настройки кнопки power.

Дело в том что bash сам по себе не является языком программирования. Он - просто связующий клей который вызывает внешние утилиты. Поэтому если у вас задача серъезная - то берите Perl/Python. Там есть сильные средства для процессинга текста и отчотов.

Bash подойдет только до первого out of memory как только у вас зайдет файл превышающий оперативку. Или просто зайдет "технически"-нетекстовый файл где строки будут сверх-длинные или просто вызывающие побочные эффекты. Обработать такую ситуацию в ЯП - нормально а в баше - сложно.

Если часто удаляется папка с over миллиардом файлов то можно пересмотреть эту задачу архитектурно. Например смонтировать эту папку как volume и форматировать ее. Это быстрее. В противоположность, файловые удаления по 1 штуке требуют фиксации транзакции для каждого файла. А это избыточные действия которые как раз и создают поток IOPs над структурами данных ext4. По аналогии с БД. То что делает автор это удаление каждой строчки из таблицы с коммитом. А то что я предлагаю - это по смыслу truncate table.

Почти таже самая проблема на стареньком HP Core i3. Пока стояла десятка все норм. Как только поставил Ubuntu 18 LTS - пошли регулярные дисконнекты. Субъективно вижу что очень низкая чувствительность антены приёмника в ноуте. Грешу на хреновые дрова. Так и не пролечил.

Workaround: Когда включаю смартфон в режиме wifi-точки и ложу его рядом прямо с корпусом ноута - связь появляется.

Автор пытается делать стеганографию. Тоесть в картинке скрывать информацию. Здесь выбор PNG полезен тем что инфа лежит плотно и в случае "гладкого" характера информации сжимается. Наподобие архиватора.

SVG - не подходит т.к. векторный и расточительный.
JPG - тоже не подходит т.к. повреждает информацию. Ее потом нельзя будет извлечь из файла без потерь.

По поводу дополнения файла до размера кратного длине строки (padding). Там не 00 не FF не подходит. Так как в оригинальном файле тоже могут быть эти константы и алгоритм даст сбой. Надо почитать как делается в криптографии. Там есть специальный workaround. Если его не реализовать правильно то при обратном декодировани картинки в файл мы можем получить ложное удлиннение файла на размер хвостика последней строки пикселов. Насколько это большой дэмедж для исходного файла - ХЗ. Но лучше конечно его не нелать чтоб обратное декодирование было надёжным с точки зрения длины файла.

Полностью согласен с ораторами насчет виртуализации.

По поводу ситуации что уже случилась. Скорее всего заход в баш вам ничего не даст. Т.к. любые команды что вы будете выполнять будут запускать процессы и вы будете снова и снова получать ту-же ситуацию что и с башом. Тоесть каким-то чудом зашли но ничего сделать толком нельзя.

Нужно 100% собрать логи и посмертные снимки памяти приложений. Или приложения. Скорее всего оно одно. И оно-же является источником проблемы. Это приложение надо перенести в докер к лимитами по памяти и там запускать.

Дампы памяти надо проанализировать и понять что флудит. С точки зрения приложения должны быть какие-то гарантии или требования по штатному режиму работы. Тоесть если ему надо 8Г то дайте ему ровно 8 и не больше.

На базе стандартного файлового API скорее всего невозможно. Объясню почему. Linux оперирует файловым API на уровне команд open/close/seek/read/write. Это основа которая работает для всех файловых систем. Если опуститься на уровень какой-то специфичной файловой системы (например vfat) то можно наверное порезать файл на кусочки кратные размеру блока файловой системы без пере-аллокаций. Но это - грязный хак который будет работать только под root и только для specific файловой системы. И только для особых условий (граница блока). Вобщем технически это сделать можно но использование этой утилиты будет носить "разрушительный" характер наподобие утилит parted, fdisk, mkfs.* и прочих. Сильно сомневаюсь что такая утилита будет полезна и востребована. Лучше пользоваться нормальным API.

grep -v оставляет весь текст кроме указанного шаблона.

Автор правильно написал в первом посту.
dd if=/dev/urandom > /dev/sda3
Запись рандомного шума лучше чем любые фильмы. И быстрее.
Можно добавить через точку с запятой последовательность диск-дубликаций для всех дисков в системе.

dd if=/dev/urandom > /dev/sda1 ; dd if=/dev/urandom > /dev/sda2 ; dd if=/dev/urandom > /dev/sda3

Выбросит или нет из ssh уже не имеет значения. 3 команды пошли в исполнение.

Очень хочется посмотреть на разработчика который занимался компилляцией bash-scripts. Скрипты вообще создавались не для перформанса а просто для организации пакетного исполнения экзешников в определённом порядке или для инсталляции и развёртывания ПО.

Это очень коварный вопрос. Само по себе бэкапирование - это безсмысленная операция если нет четкого сценария ЧТО мы бекапим и КАК мы это дело будем поднимать. Ведь бэкап это тупо набор файлов. Образов или логических копий файлов. Поэтому успех этого мероприятия будет зависеть не от того берем мы rsync или tar или еще бох знает что. А от того какая конфигурация дисков на резервной железке. Какие ендпоинты надо поднять. И надо-ли вообще бэкапить всё? Для серверов приложений например на базе Tomcat/JBoss вам достаточно забэкапить только каталог приложений и настройки и возможно OS environment. Для баз данных там еще все запутаннее. По Oracle RMAN написана книжка размером с пятикнижие Моисея. Вобщем совет автору не бэкапить а провести сценарий полной инсталляции продукта в новое место. Оттуда и появится инструкция по техологии плановых бэкапов только нужный вещей.

Такая конфигурация не имеет право называться базой данных. Присоединяюсь ко всем ораторам. Просто добавлю что портативное устройство должно писать логи операций. Чтобы выполнять разбор полетов и фиксировать что делалось. Можно с ротацией. А база данных должна лежать отдельно. На надежных удаленных серверах.

MySQL - это не совсем DBMS. Это сборный лего-конструктор в котором каждая таблица в отдельности сама определяет свой уровень отказоустойчивости (т.н. engine). Поэтому обсуждать надёжность MySQL нет смысла без обсуждения того как была создана каждая таблица. In general - про надёжность сказать ничего невозможно.

Откуда взялось это техническое задание? Это очень напоминает механику хеширования файлов. Как делают браузеры при сохранении статического контента. Не сложно сделать баш-циклы. Но гораздо полезно понять почему автор этого хочет. Что будет если файлов станет 10001 ? Как именовать каталоги?

ext4 не поддерживает объединение в логические тома. Если-бы при устанвке был использовал LVM (хотя это боян еще тот) или файловые системы такие как BtrFs, Zfs тогда эту операцию можно было-бы провести. Конечно обязательно проконсультиоровавшись с знакомым сисадмином. Тут основная беда в том что это опасные операции и необратимые. Любая ошибка - и ваши данные потеряны причем на многих разделах сразу.

А так... подключите /dev/sda4 просто как папку например /video и используйте.

Судя по профайлу автор - виндузятник причем ему требуются чисто виндозные целевые инструменты разработки такие как C#/Visual Studio. Ничего подобного в линуксе нет и не предвидится. (Любители моно сейчас сидят тихо).

Поэтому переходить ему никуда не надо. Следует оставаться на винде. Ну а если сильно припекло - изучать Linux на виртуалках или прикупить дешевое железо. Благо существуют спец-редакции линуксов которым достаточно слабых машин с 2-4 гигабайтами памяти. Это правда.

Посмотрите black-list Emule. Там может быть эта информация.
emule-security.org