В больших сетях административные интерфейсы активного оборудования выводятся в отдельную подсеть. А то и не одну.
В небольших обычно используется одна подсеть для активного оборудования и административных интерфейсов серверного оборудования.
В малых сетях вообще порой используют одну подсеть на всё - тогда рекомендуется серверным оборудованием занимать начальные, а коммутационным последние адреса подсети (само собой, эти адреса не входят в DHCP-скоп).
Знакомые говорят, что y обычных коммутаторов вообще нет ip, а только у L3
Следует различать административный интерфейс (используется для управления и мониторинга, есть у L3 и у управляемых L2) и клиентский (маршрутизирующий) интерфейс (используется в качестве шлюза при маршрутизации клиентского трафика, есть только у L3).
Да, между узлами сети провайдера всё бегает в соответствии со скоростями портов коммутаторов (ну скажем 100 Мбит), и в принципе провайдеру на этот трафик наплевать, но к этому нужно ещё и пачку энтузиастов, которые выставят в сеть подобные сервисы. Впрочем, да, тут за народом не заржавеет, когда у нас была горсеть, там чего только не было доступно без выхода наружу и соответственно тарификации. А для выхода в Инет - VPN-клиент, и QoS следил, чтобы не было проблем.
Но тут есть куча граблей, от которых провайдеру будет сплошная головная боль. Попадётся вот с тобой на домовом коммутаторе перец, который поднял торрент-трекер и имеет неслабое хранилище. И сосут с него в сто потоков разные товарищи. А у тебя в итоге канал в Инет не 10 абы гарантированных мегабит, а дай бог два процента от них. А ты ж за ширину платишь - и вот у провайдера заявка, которую он обязан отработать.. Или ещё хуже - находится в сети малолетний придурок, которому руки чешутся свежескачанный NetBIOS-сканер попробовать, у тебя файрвол взрёвывает, ты жалобу провайдеру, а он опять обязан реагировать.. и таких ситуаций предостаточно. Вот оно провайдеру надо? И если у него задача не организовать и поддерживать горсеть, то он вполне обоснованно переводит все порты в изолированный режим. Он получает деньги за доступ в Инет - вот нахрена ему обеспечивать кого-то за просто так ещё какими-то сервисами?
Основной, и даже единственный, вопрос, на который надо найти ответ - нахрена бы это было надо провайдеру? Лишний геморрой, причём неслабый, и при этом вообще никакого монетизируемого профита.
В общем, я бы сказал, что даже теоретической возможности - и той нет.
То есть если бы вес был 0.234, 0.235 и 0.236 - было бы всё в порядке, выводить не нужно, ибо первое округлится в 0.23, а остальные в 0.24? Похоже на какую-то дурь...
Как по мне, так надо смотреть по разнице qty и LAG(qty,2).
Да переведи ты принтер в приостановленное состояние да с утра посмотри, откуда создано задание... ну что как маленький-то?
Заодно включи (если не включен) расширенный лог, чтобы и станцию, и пользователя, и время определить.
Вот всё одно не могу понять такого упорного цепляния за Memory engine.
Ну в качестве эксперимента всё же переведи таблицу в InnoDB и посмотри, как будет выглядеть процесс. Без всяких там рамдисков для начала, с таблицей на SSD. Думаю, что после тестов необходимость столь глубокой оптимизации, которой тут было запахло, тихо скончается.
Всё же MyISAM/Memory оптимизировано под высокое соотношение чтение/запись.
Всё же переходи на статические таблицы и InnoDB. Memory под капотом - та же MyISAM, и от табличной блокировки тут не убежать от слова "совсем".
С другой стороны, создаётся у меня впечатление, что ты блокируешь таблицу насмерть, пока программа там что-то считает, хотя надо минимизировать время работы с таблицей. Подключился-записал-отключился.
Какой у тебя получается поток запросов? среднее количество в штуках по каждому типу в секунду, плюс по ним же среднее количество записей...
На сколько мне известно, он ее сначала записывает на свой диск
Как правило, это неверно.
Информация с камеры поступает в оперативную память регистратора. Оттуда она и пишется на диск, и передаётся потребителю. Кстати, именно поэтому live video на сервере нельзя поставить на паузу.
В небольших обычно используется одна подсеть для активного оборудования и административных интерфейсов серверного оборудования.
В малых сетях вообще порой используют одну подсеть на всё - тогда рекомендуется серверным оборудованием занимать начальные, а коммутационным последние адреса подсети (само собой, эти адреса не входят в DHCP-скоп).
Следует различать административный интерфейс (используется для управления и мониторинга, есть у L3 и у управляемых L2) и клиентский (маршрутизирующий) интерфейс (используется в качестве шлюза при маршрутизации клиентского трафика, есть только у L3).