Search
Write a publication
Pull to refresh
-20
0.1
Send message

Приточка с улицы - источник пыли, что для серверной очень плохо.

У нас в "серверной" два кондея, один летний, другой зимний. По смыслу они одинаковы, но у "зимнего" внешний блок висит не на улице а во входном коридоре-тамбуре, и зимой хорошо его отапливает. Зачем выкидывать тепло на улицу если можно использовать с пользой. У "летнего" кондея внешний блок на улице, и его приходится обслуживать, чистить от пыли. У "зимнего" внешний блок в помещении, и в таком обслуживании он не нуждается.

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

Два кондея - это еще и резервирование. Если летом сдохнет летний - можно включить зимний, открыв дверь из тамбура на улицу. Если зимой сдохнет зимний - то если не сильный мороз, то можно попробовать включить летний. Если сильный мороз - то придется просто проветривать, на время ремонта. На этот случай есть воздушный канал между серверной и it-отделом, с мощным вентилятором. Но для отопления it-отдела этот метод на постоянку не используется т.к. натянет пыль в серверную.

Там поди был какой-то старый Firebird архитектуры супер-сервер, который не умеет параллелиться. Старый сервер был, условно с одним ядром, но с большой частотой, и FB его успешно использовал. А на вашем новом сервере поди 64 ядра, но с частотой в 3-4 раза меньше, вот FB сел на одно медленное ядро, и слил всю скорость :)

На заглавной картинке КДПВ, в штампе подписи, указаны странные сроки. Дата окончания меньше даты начала действия. Там данные совсем с потолка, или где-то в коде есть ошибка?

Оно не узкое. После того как актуальность версий заканчивается, это место будет в дальнейшем использовано. Уборка "мусорных версий" производится при обращении к записи, сервер определяет какую из версий может видеть клиент, а какие версии уже никому не нужны. Т.е. убирать будет не тот кто эти версии создал, или удержал, а следующий за ними клиент/транзакция. От этого есть несколько решений - не держать длинных транзакций без необходимости. При удалении большого количества записей лучше тут же их прочитать, из той процедуры которая удаляла, но в новой транзакции. Таким образом замедление будет у того кто удалял а не у следующего, типа "необъяснимое торможение".

Так что совершенно не факт что " отдельный undo log лучше ".

Чтобы узнать размер страницы вашей базы данных, воспользуйтесь командой:

В Windows:
gstat.exe -h Disk:path\database.fdb

В Linux:
gstat.exe -h Disk:path\database.fdb

Для Linux, видимо, должна быть несколько иная строка.

В отличие от косилки управляемой человеком-оператором, робот может работать в нонстопе круглосуточно, прерываясь только на зарядку. За счет частого кошения скошенная часть очень мелкая и ее буквально не видно. Это даже не мульча а еще мельче. Она падает на грунт между травинок и очень быстро уходит в грунт, перегнивая.

Робот-косилка - это не скосить бурьян, это поддерживать в заданном состоянии газон, подготовленный для робота заранее. Высокую траву он не возьмет. Поэтому робот-косилка - это не вместо обычной косилки, а в дополнение к обычной. Иначе вы не сможете эксплуатировать робот в случае каких-то эксцессов. Ну и обычно не 100% площади покрыто роботом, остаются участки которые для робота подготавливать неэффективно (далеко кабель тянуть, препятствия, трава растет за забором за пределами вашего участка и выпускать туда робота опасно), поэтому всегда есть работа и для обычной косилки, но конечно в гораздо меньшем объеме.

Про робота-газонокосилку написана полная фигня, не имеющая отношение к жизни роботов :)

Роботам по самой идее автономной работы не нужен бункер для сбора травы. И никакого сена после робота не остается, и даже если постараться - после робота ничего граблями не соберешь.

Роботы бывают с разным принципом управления - через заложенный в землю/траву кабель, лограничивающий периметр и задающий зоны, или сейчас уже появились в продаже роботы которые умеют работать без кабеля, ориентируясь по датчику координат относительно базовой станции-излучателя.

Роботы бывают расчитаны на разную площадь кошения, и это существенно влияет на их цену.

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

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

У Алексея Надежина весьма информативные обзоры про роботы-газонокосилки.

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

БП ноута можно или оставить снаружи т.к. он пыли не боится, либо прикрутить к металлическому ящику изнутри или снаружи, что бы улучшить охлаждение. Если штатный БП совсем мелкий, расчитанный на втыкание прям в розетку, то можно купить универсальный, побольше мощностью, что бы меньше грелся.

Мне кажется что при сравнении не учтено что у PostgreSQL есть еще журнал транзакций который хранится вне базы, и растет при работе с базой, что вызывает необходимость его потом как-то урезать. У Firebird отдельного журнала нет, эта инфа пишется в самой базе.

Опечатка: " В завяленные сроки ".

У draw.io есть и офлайн-версия, можно поставить приложение себе на комп.

Про экономию 200т.р. написано прямо в заголовке. Люди читают статью и не могут найти откуда такая экономия вообще получается.

Мне статья понравилась, но для того что бы понять про что она, потребовалось прочитать 2-3 раза. Сама задача выглядит странной, но интересно было посмотреть пример применения HomeAssistant и умных девайсов. Обычно примеры сильно притянуты за уши, а в данном случае получилось просто (с учетом что HA уже был) и эффективно (заменили одну лампочку на умную, сделали скрипты-настройки в HA).

Сейчас дофига машин где у АКПП есть ручной режим, а переключать передачи можно подрулевыми лепестками.

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

Мне смутно помнится, что когда Дуров первый раз хотел запустить свою валюту TON, то в США были сильно и продуктивно недовольны, и Дуров от TON отказался.

И вот, вроде бы недавно этот TON таки запустили в работу. Возможно с этим и связаны претензии - валюты-конкуренты никому не нужны.

Они ездят не по асфальту, а по специальной грунтовке для танков и прочей техники. Асфальтовую дорогу пересекают один раз, и в этом месте дорогу забетонировали. Так что "своим ходом" - это не совсем так, просто у них обучение начинается не на самом полигоне а прям от училища, и дорога как-бы входит в полигон.

Создаем файл с кредами

mount -a

Тут какая-то другая команда должна была быть?

Firebird так умеет.

hostname -I

Неправильно (заглавная I). Правильно так:

hostname -i

Если записать тот же самый запрос по другому, то становится виднее "почему так".

SELECT SUM(o.amount)

FROM operation o

INNER JOIN operation_tag ot1 ON (ot1.operation_id = o.operation_id )

INNER JOIN operation_tag ot2 ON (ot2.operation_id = o.operation_id )

INNER JOIN operation_tag ot3 ON (ot3.operation_id = o.operation_id )

INNER JOIN tags t1 ON (t1.tag_id = ot1.tag_id )

INNER JOIN tags t2 ON (t2.tag_id = ot2.tag_id )

INNER JOIN tags t3 ON (t3.tag_id = ot3.tag_id )

WHERE (1=1) AND (o.created_at BETWEEN '2023-08-01' AND '2023-08-31')

AND (t1.name = 'provider' ) AND (t1.value = 'someProvider' )

AND (t2.name = 'merchant' ) AND (t2.value = 'someMerchant' )

AND (t3.name = 'customer_id' ) AND (t3.value = 'someUniqueCustomerId')

Мда... форматирование в каментах неудачное...

Открылась его копия, и не одна.

https://resql.ru

Тут даже регистрироваться можно, но активность нулевая, все в телеграм ушли.

Information

Rating
8,460-th
Location
Новосибирск, Новосибирская обл., Россия
Registered
Activity