Спасибо за ответ! Сервер сейчас уже используется без nvme, поэтому тест с ними процесс не быстрый. Но в любом случае протестируем, вернусь с результатами, благодарю
RStarun, Спасибо за ответ! Посмотрю, спасибо. По поводу дефрагментации, процесс был системый, сейчас не скажу почему он запускался, пытались его отключать, но через время он запускался самостоятельно
Роман Безруков,
1. Да, лежали рядом с системой, на NVMe.
2. Формат дисков по умолчанию
3. Не тестировали, займемся в понедельник
4. 1С серверная, не файловая.
Роман Безруков, SAS, по словам админов, запускался системный процесс дефрагментации диска(упорядочевание и т.д.), 96 гб было выделено серверу рдп на первое время, но как показала практика, увеличив до 120+ это не помогло. Даже когда на сервере было 5 человек и расходовало меньше 20% всех ресурсов запускался этот процесс и расход памяти улетал в небо и как следствие падал сервер. Это одна из многих проблем, которую решили переустановкой рдп с Win server 2025 на Win server 2019.
Dmitry, я не пытаюсь проконтролировать работу админов, я пытаюсь проконтролировать процесс т.к. это поставленная мне задача. Лучшие практики или советы что может быть не так я прошу именно для того, что бы уменьшить диапазон возможных проблем и проверять поочередно причину такой работы сервера. Подскажите интегратор например кто? и как он учувствует в процессе обслуживания сервера?
Alexey Dmitriev,
Насколько мне известно, proxmox забирает 25% для работы самого proxmox, поправьте если это не так
фото/метрики тестов, увы, нет у них, но в течении использования постоянно присылают скрины по типу:
Показывая проблему нехватки памяти(на скрине показано резкое увеличение памяти при запуске процесса дефрагментации диска и последующее падение сервера
Akina, спасибо за совет по оптимизации запроса, дистинкты я конечно убрал, но правда я так и не разобрался как нужно было записывать union'ы) Вопрос отредиктировал
Благодарю, достаточно удобная команда, но встаёт вопрос, как узнать что за пользователь по uuid в выводе и не понятны все флаги доступа FA, ID и другие, котоыре явно не описаны тут
Моей целью сохранить синхронный код - использовать его для api, которые имеют низкий rps. Конечно можно и в асинхронном это решить, но я думаю, что правильней будет просто использовать синхронный подход
fenrir, целью является создание базового(ых) классов для запросов, а так же конкретные реализации для каждого маркета. Проблема заключается в том, что при масштабировании класса, например, который был изначально, становится проблематичным добавление туда новых методов, т.к. их более 50, если говорить про Озон, у других меньше, но все же. Строк кода становится более 1000 для одного класса, код во многом повторяется. Так же при появлении других классов реализации их просто будет добавить в фабрику не делая импорты. Говоря про композицию, что Вы имели ввиду?
mayton2019, не совсем понял вопроса про смешение ООП и асинхронности. Классы, которые реализуются непосредственно к какому-либо маркету не наследуются от классов запросов, если можно так выразиться, таким образом, под капотом только базовые классы отличаются. Остальные одинаковые.
