mayton2019

Так не делается.

Согласно лучшим практикам (best practices), ты должен сначала покрыть
свой код тестами. Тоесть представить на наше обозрение проект, который
компилируется и тестируется. И после этого мы сможем предлагать различные
improovements для кода базируясь на улучшении производительности
и на уменьшении например метрик code complexity.

При этом все изменения не должны ломать тесты. Это - очень важно.

По коду. Непонятно, почему в методе swapCharacters ты применил StringBuilder
и в то-же время в textModifier ты решил использовать replace и конкатенацию
строк. По отдельности к каждому методу нет вопросов. Но есть вопрос по единообразию
кода. Уж коли ты решился на суровые оптимизации скорости - то нужно выдерживать
работу в таком ключе. Это - совет по конвенции кода по отношению к своим проектам.
Договорись сам с собой. Тебе важен перформанс или просто ты делаешь POC и тебе нужен краткий код?

Когда начались тормоза, сразу добавил новый инстанс приложения, производительность практически удвоилась, но позже и второй инстанс начал задыхаться, добавил третий и производительность не увеличилась. Запустил профилировщик, увидел, что все упирается в бд, на ум сразу пришло вынести эту часть в микросервис, а основной монолит будет обращаться к этому микросервису, но опять же проблема, а что будет, когда и этот микросервис начнет задыхаться?

Вопрос интересно звучит. Как будто - куда "соломки" положить чтоб мягче падать.

Пускай планом Б у тебя будет просто поднятие еще одной БД или нескольких БД с балансировкой.
Если 1 база не успевает отработать поток, по пол-потока или треть она успеет.

Попробуй мемоизировать результат ответа от БД. Положи в Redis. Это на тот случай если есть
горячие комбинации парамтеров запроса и есть вероятность что клиент их затребует несколько раз.

Подскажите, что можно предпринять (если менять архитектуру, то на какую)? Пожалуйста, подробнее и более простым языком (для тупых).

На данный момент ничего менять не надо. Т.к. непонятно в какую сторону тебе двигаться.
Однозначно тебе нужен хороший специалист по БД. Он должен уметь смотреть execution
plans и давать советы по тому какой сет индексов построить. Иногда помогает переход
в архитектуру Key-Value dbms (если это только не противоречит бизнесу). Поэтому я не скажу
что это совет. Это скорее мысль, о чем можно говорить с бизнесом.

У тебя две задачи.

1) Первая - это пересечение треугольника и прямоугольника. Я не помню никаких
названий или реализаций этого алгоритма. Да. Сазерленд тебе будет полезен. Но он решает
только прямую и прямоугольник. Попробуй рассматривать треугольник - как многоугольник
и отрезай от него по одной стороне с 4 сторон.

2) Вторая называется - триангуляция. Она много где описана в инженерной графике. Книг
точно не помню но поищи. Шикин и Боресков. Эгрон. Павлидис. Они точно должны были
что-то писать про это.

В терминологии С++ выше double (64bit) находится __float128.
Я-бы проверил поддерживает ли CUDA/OpenCL эти типы
на уровне API. Если вдруг не поддерживает - то придется
их реализовывать самому.

До того как их реализовывать я-бы спросил у автора - действительно
ли ему нужны числа с такой мантиссой и экспонентой как он хочет
и для каких алгоритмов. В большинстве случаев в алгоритмах
всегда есть маневр. Есть возможность где-то срезать углы и не делать
избыточных расчетов. Тем более что для нужд физики обычного double
хватает. Что такого надо считать чтобы double не хватало - я не знаю.
Поперечник обозримой вселенной в пропорции к планковской длине?

У меня давным давно была подобная проблема. И я помню что мы делали упаковку клиента БД
в MSI-Installer.

Развернуть дистрибутив. И добавить парочку ключей в реестр - все это работало.

https://learn.microsoft.com/en-us/windows/win32/ms...

По поводу самораскрывающихся архивов (WinRar, упаковщиков и кастомных инсталлеров).
Вот у врачей есть такое выражение - благоприятная среда
для развития микробов. Вот это выражение здесь подходит. Из всех изобретений Microsoft - sfx
архивы это древнее хтоническое зло, которое никогда не должно было быть создано.

Python исторически не создавался для компилляции в бинарники.

Попробуй реализуй свою задачу на языке Swift. Это как раз для Мак-ов язык и для компилляции.

Звонок действительно может быть - частью коллекторской активности которая собирает живые номера.
Но взлом происходит не через звонок а через анализ социальных сетей, где ваш телефон мог появлятся.

Поэтому - ответ нет. Но будьте внимательны к тому что пишете и публикуете. Какие у вас пароли?
Везде ли одинаковые? Есть мультифакторка? Как часто устанавливаете себе на телефон игры
и прочие развлекательные приложения?

Incscape по идее умеет переводить растровые картинки в вектор.
Но результат будет сильно зависеть от качества исходной картинки.

Вариант

$ oggdec file_example_OOG_5MG.ogg file_example_OOG_5MG.wav
$ lame file_example_OOG_5MG.wav

И из Go соотвественно надо вызвать внешний процесс

exec.Command(".....")

Геркон - это выключатель. Пассивное устройство. И он ничего не потребляет. Поэтому можно
включить их бесконечно много. Насколько хватит денег.

Возможно к 20 пинам подключить 100 клавиш клавиатуры. Но надо как-то с самим собой
договориться что мы не будем играть в игры и давить сразу 2 или 3 клавиши одновременно.
Кажется такая схема в старых кнопочных телефонах использовалась где были цифры от 0 до 9
и символы * и #

Документация упоминает утилиту

gcloud firestore export ...

https://firebase.google.com/docs/firestore/manage-...

Попробуй сохрани базу в файл. Если он имеет вид JSON то тебе повезло.

Классические реляционные СУБД (MySQL) плохо приспособлены к хранению бинарных
файлов. Все дело в размере строки. Исторически 1 строка (data_row) в БД не превышала 4-8 килобайт.
Исходя из этого ограничения БД проектируют кеш и алгоритмы когеретности по кешу.
И все работает отлично до тех пор пока вы не начинаете миксовать крупные файлы и строку БД.
В этом случае мехнизм кеширования БД ломается и БД вынуждена ходить в disk (tablespace)
который по total cost of ownership всегда стоит дороже чем обычный диск, и тем более дороже
чем хранилище AWS/MS-Blob/GDrive. Дороже будет стоить бэкап базы данных которая на 95%
к примеру состоит из JPG картинок вместо реляционных данных. Такова специфика дискового
пространства почти любой БД. Не удивляйтесь если облачный биллинг вам выкатит счет
по которому JPG картинки будут стоить как крипта. Дороже будет сетевой траф для публикации картинки
ведь вам надо сделать сначала трансфер этих мегабайтов с хоста MySQL в Node/Tomcat/Apache
и лишь только потом сделать еще один трансфер с веб хостинга к клиенту. Трафик - 2x.

Поэтому имеет смысл толстые картинки положить в обычный диск под веб сервером Apache
или пошарить хранилище через web-endpoint. В этом случае биллинг за хостинг картинок
для вас станет хотя-бы разумным. А в реляционной базе хранить тольк URL на этот диск.

Некоторые советы по вопросу. Первое.

Совет бывшего создателя - убивать приложения через taskkill конечно очень порадовал.
Было-бы неплохо чтобы создатель также помог автоматизировать процедуры восстановления
файлов и данных после такой спорадической стрельбы. Вообще не существует не-деструктивного
способа забрать выделенную память у приложения. Таковы реалии. Если программист зачем-то
выделил память - значит нужно. И фиксацию этого можно сделать только в исходном коде
приложения.

Второе. Если вы - сисадмин, который занимается развертыванием и сопровождением программных
продуктов то вам должны были дать инструкции по всему этому. Поищите в документации
секцию настройка или configuration. Там должно быть что-то вроде buffers, threads, workers, memory_pool e.t.c.
В ini files или в реестре.

По терминологии. Никакого ОЗУ уже давно не существует с точки зрения приложений. Это - старый
термин из 20-го века и его надо как-то убрать из вопроса. Современная память приложений - это
virtual memory которая представляет собой бутерброд из ОЗУ и Paging File (Swap file в разных ОС).
По факту приложения могут выделять больше памяти чем есть в ОЗУ но при этом сохранять свою
работоспособность. Но механика сброса страниц или чтения может сыграть роль performance issue,
которое надо оценить в виде метрики.

Поэтому если автор хочет понять влияние памяти на приложение - я вижу единственный вариант
- придумать метрику работы приложения (например количество отработанных транзакций в секунду
в нормальном (номинальном) режиме работы) и запомнить ее. Это будет base line или некая хорошая
горизонтальная линия на графике. Или какой-нибудь квартиль или процентиль от времени отклика.
Далее - наблюдать эти графики в Grafana или каком-то другом графическом мониторинге.

По поводу процессов сsc.exe и conhost.exe. Это - консоль и компиллятор Microsoft C#. Тут - мало информации
к расследованию. Скорее всего их наличие - это просто дизайн и архитектура. Но если автору интересно -
пускай поищет командную строку (те символы которые идут после csc.exe). Возможно будет какая-то
более ценная инфа.

Современные процессоры уже кодируют mp3 быстрее чем требуется для онлайн трансляции.
Поэтому острой необходимости нету. По поводу CUDA я не специалист. Но практически все
задачи подобного толка решаются через шаблоны fork-join.
Если ты сможешь взять поток mp3 и порезать его на совокупность кадров. И для каждого
кадра очень эффективно создать этот самый fork-join и успеть очень быстро собрать результаты
всех потоков в новый поток - то твоя задача вполне себе осуществима. Но будет ли от этого
ощутимый эффект - чорт его знает. И не будет ли потерь на координации ядер и потоков.
Задачи майнинга к примеру выигрывают на том что у них редкая координация. Раз в 10 минут
получили задание - загрузили каждый камень и спокойно себе считают. С mp3 будет по другому.

Несколько мыслей.

Копировать рабочие станции - это впустую тратить дисковое пространство. Имеет смысл изучить ценную
информацию на десктопах и копировать их точечно. Например - копировать только Мои Документы.
И только файлы определенной сигнатуры.

Настройки приложений - по максимуму вынести в домен-контроллер. В идеале все настройки должны там
быть.

Сам процесс копирования не имеет смысла без тестов восстановления.

Непонятно каким образом вы от проблемы PostgresQL перешли к проблеме zfs?

Мне кажется что существует только один способ проверки работоспособности снепшота.
А именно - сразу после того как он сделан - поднять на нем БД и посмотреть что в журналах
нет ошибок. Если ошибки есть - повторить снепшот еще раз.

Sad, but true.

RandomAccessFile, FileInputStream - это абстракции поверх системного I/O. В идеале они должны
иметь всего 1 метод. Чтения блока байтов в буфер. Но идя навстречу разработчику они любезно
добавили чтение примитивов чтоб читать двоичные форматы например JPG, MP3, SQlite и прочее
в виде sequence из примитивов в правильном порядке.