В топике нет проблемы как таковой. Проверки можно делать по разному. Но главной метрикой скорее всего будет - компактность кода и скорость внесения в него изменений. Из best practices. Заводите вспомогательный класс. Helper. И делаете 20+ методов.
Полностью согласен с ораторами насчет виртуализации.
По поводу ситуации что уже случилась. Скорее всего заход в баш вам ничего не даст. Т.к. любые команды что вы будете выполнять будут запускать процессы и вы будете снова и снова получать ту-же ситуацию что и с башом. Тоесть каким-то чудом зашли но ничего сделать толком нельзя.
Нужно 100% собрать логи и посмертные снимки памяти приложений. Или приложения. Скорее всего оно одно. И оно-же является источником проблемы. Это приложение надо перенести в докер к лимитами по памяти и там запускать.
Дампы памяти надо проанализировать и понять что флудит. С точки зрения приложения должны быть какие-то гарантии или требования по штатному режиму работы. Тоесть если ему надо 8Г то дайте ему ровно 8 и не больше.
Это похоже на Транспортную Задачу. Почитай описание.
Кроме того ты должен обозначить что ты понимаешь под эффективностью.
В некоторых случаях это может быть - заработать больше денег.
А в некоторых случаях - не оставить ни одного человека незаселенным.
Или просто уменьшить простой номера.
База данных в таких случаях не подходит. Она не умеет индексировать "по ключевым словам". И выражения с LIKE обычно дают плохие планы выполнения т.к. искомое стоит в середине строки. Классический базёвый индекс в таких случаях не работает. Можно поробовать оффлайновый индекс по товарам с использованием Apache Lucene. Но это потребует определённых усилий по подготовке и актуализации такого индекса. Грубо говоря его надо постоянно синхронизировать по новым товарам.
На базе стандартного файлового API скорее всего невозможно. Объясню почему. Linux оперирует файловым API на уровне команд open/close/seek/read/write. Это основа которая работает для всех файловых систем. Если опуститься на уровень какой-то специфичной файловой системы (например vfat) то можно наверное порезать файл на кусочки кратные размеру блока файловой системы без пере-аллокаций. Но это - грязный хак который будет работать только под root и только для specific файловой системы. И только для особых условий (граница блока). Вобщем технически это сделать можно но использование этой утилиты будет носить "разрушительный" характер наподобие утилит parted, fdisk, mkfs.* и прочих. Сильно сомневаюсь что такая утилита будет полезна и востребована. Лучше пользоваться нормальным API.
Такой IDE не существует. И не будет существовать. Объясню почему. В инфо-технологиях существует класс задач которые нельзя решить "просматривая глазами код". Например нельзя доказать что код обладает каким-то свойством. Например свойством что он остановится с гарантией после 100000 итераций. Чтобы такое доказать надо этот код скомпилировать и запустить. Грубо говоря рантайм или собственно работа кода является доказательством его правоты. И никакие статические анализаторы не способны глянуть глубже чем рантайм.
Почему здесь важен рантайм? потому что автор говорит об алгоритмах сортировки и из контекста вытекает что его интересуют задачи именно производительности и скорости.
Еще альтернативный вариант - просмотр кода человеком. Это работает. Иногда.
Статические анализаторы могут просто подсказать какую-то простую ошибку типа потенциальный NPE или выход за границы массива. Но только в очень простых кейсах.
В книге Холдена Карау - "Изучаем Spark" - глава 9 Spark SQL этому вопросу уделелено 1-2 странички. Можно почитать.
Кешировать "каким-то образом" можно "всё что угодно". Redis и прочие коробочные решения для кешей - работают
но они к технологии Spark не имеют никакого отношения. Собственно их можно советовать как универсальный
совет для любых систем которые имеют back-end. Интеграция их же со спарком это вообще отдельный вопрос.
С помощью Java Security Manager можно избирательно перекрыть приложению возможность прослушивать порты листенера, или создавать самому соединения. Но этот менеджер не различает ендпоинт и базу. Ему нужны цифры вида host:port или их комбинации и рулы разрешений на соотв действия.
Автор пытается построить свой прикладной протокол поверх сокетов. Этого не надо делать т.к такие протоколы уже созданы. Ключевые слова: jms, mq, apache-mq, kafka, rabbitmq, ibmmq.
Очень похоже на задачу об укладке рюкзака (knapsack problem). Можно начать с того что есть 2 рюкзака. Один изначально пуст. А в другом - все предметы. И есть некое значение массы (сумма весов всех предметов) деленная пополам.
Вот к ней надо стремиться.
Вопрос непонятен. Если CriteriaApi может получить stream произвольных объектов (UserEntity) то
к стриму всегда можно применить метод map и взять только нужый стрим полей.
C++ сегодня очень сложен как язык. Порог вхождения высок и новички часто обламывают об него зубы доходя лишь до арифметики указателей. Там - половина ньюкамеров можно выносить ногами вперед. Скорость разработки прикладного ПО под backend на Java значительно выше. Да и облачные технологии такие как Google Clound , Amazon AWS поддерживают все языки кроме С++. Вобщем если автор хочет быстрых денег - то лучше Java.
В С++ надо вырасти до седых волос чтобы представлять что-то серъезное потому-что стек С++ плотно уходит в операционную систему и железо. Невозможно знать просто С++. Надо быть немного сисадмином и железячником. Иначе в С++ делать нечего.
Не очень понятен смысл этого доклада. Вроде как it-археология еще не появилась как наука.
Java Appletts, ActiveX, Macromedia/Adobe Flash - это всё технологии которые умерли и браузеры их не поддерживают. В этом будет основная проблема при написании доклада. Некуда смотреть во время demo. Документация по ним скорее всего есть в архивах oracle.com (sun.com) надо просто искать мануалы от 90х 2000х годов на сайте производителя. Думаю что можно найти очень много старых электронных pdf книжек на эту тему.
Автор правильно написал в первом посту. dd if=/dev/urandom > /dev/sda3
Запись рандомного шума лучше чем любые фильмы. И быстрее.
Можно добавить через точку с запятой последовательность диск-дубликаций для всех дисков в системе.
Очень хочется посмотреть на разработчика который занимался компилляцией bash-scripts. Скрипты вообще создавались не для перформанса а просто для организации пакетного исполнения экзешников в определённом порядке или для инсталляции и развёртывания ПО.
