calculator212, я не знаю деталей того, зачем вам понадобилось оптимизировать работу памяти. Я бы не приступал к этому процессу без конкретных причин.
Этот флаг скажется на производительности, поэтому если память не нужна хосту немедленно, не стоит её возвращать принудительно.
Следует мониторить метрики хоста и приложения, иметь оповещения на отклонения от нормы и только в случаях отклонения приступать к оптимизации работы компонентов приложения и ос.
https://golang.org/doc/go1.12#runtime
Там можно прочитать про MADV_FREE.
Т.е. поведение по умолчанию освобождает память, но ядро не забирает освоьодившуюся память, если в ней нет необходимости. Предлагаю провести тест отключив этот флаг. В таком случае, как я полагаю, память будет возвращена немедленно.
С написания ТЗ и поиска разработчика на Python, который напишет недостающий класс для подключения по TCP вместо COM.
Но прежде чем давать такое ТЗ разрабу, лучше конечно удостовериться, что если команду отправить ко COM-порту и такую же отправить через какой-нибуть netcat/telnet - получится одинаковый ответ от устройства. Тогда можно с уверенностью сказать что только транспорт для этого протокола отличается.
Ну и как eegmak советует - так же можно поступить. Если из всего протокола требуется разве что одна команда, проще разработать софтинку/скриптик которая эту команду и отправляет. Хоть используя тот же bash и netcat, если уж совсем упрощать. А дальше такой скрипт можно скормить, например, Заббиксу. Или Nagios. Или ещё какой системе мониторинга.
Виктор Путин, логично. С любым циклом так будет, пока ваш алгоритм продолжит учитывать лишь проверку последнего. Нужно либо прерывать цикл при первой же ошибке, либо устанавливать флаг, что при проверке были найдены ошибки, либо придумайте какой-то свой вариант
Похоже, протокол по COM/Ethernet идентичный. Можно брать за основу pyshtrih и, наследуясь от Device, заменить подключение через com на установку tcp-соединения. В теории, сработает.
Muxauko, нет, блокировки нужны на уровне БД с применением транзакций.
Чтобы что-то еще сказать, хорошо бы указать какие операции с базой асинхронно не работают (один простой UPDATE может выполняться без последствий), какой движок БД используется (так как InnoDB уже по умолчанию все запросы выполняет транзакционно), в какую ошибку вываливается. Там один UPDATE или ещё какие-то запросы?
Muxauko, хм, понятно. Это вопрос не к драйверу, или языку, а к тому как вы с SQL работаете. Используйте блокировку на строках которые меняете, используйте транзакции для атомарных изменений. Вариантов решения много - они будут зависеть от вашей бизнес-логики.
Главной таблицей для paragraph является manual - оставьте язык только в manual.
Связь author и manual - один ко многим. И тут зависит от того как создается новая запись в авторах. Если автор заводится отдельно от мануала = поле lang ему нужно для упрощения последующеего связывания с мануалом в качестве фильтра. Если автор создается одновременно с мануалом и просто матчится по имени - lang можно опустить, в нем нет смысла. В особенности в приведенном примере, где en и de написание имени автора идентичны.
Виталий Гусев, Спарк - коммерческий продукт,
как работает smart-search в деталях - публично неизвестно. Стоит обратиться в поддержку спарка с проблемой поиска, как они и пишут в своей доке.
Можно проверить на стороне сервера - используется ли imap search. Если нет - то это чисто кривизна клиента. Если использует - значит ещё можно покрутить конфигурацию сервера, в надежде что это как-то поможет Спарку. Кстати, какой у вас IMAP сервер?
Этот флаг скажется на производительности, поэтому если память не нужна хосту немедленно, не стоит её возвращать принудительно.
Следует мониторить метрики хоста и приложения, иметь оповещения на отклонения от нормы и только в случаях отклонения приступать к оптимизации работы компонентов приложения и ос.