Buffer full drop что это

1) Input buffer full — переполнение входного буфера на порту.

2) Packets denied by ACL — пакеты отброшенные ACL.

3) VLAN ingress checking — проверка по VLAN на входе.

Продукты и решения
О компании

Сервисное обслуживание
Предоставление оборудования на тест
Загрузки
Технический форум
F.A.Q
Эмуляторы
Обзоры

Семинары / Дистанционное обучение
Программы учебных курсов D-Link
Авторизованные учебные центры D-Link
Получение сертификата D‑Link
Плакаты

Где купить

Дистрибьюторы
Проектные партнеры
Авторизированные партнеры

Buffer full drop что это

Roman

15.05.2016
18:52:34
пытался eoip поднять, нифига

Vlad

15.05.2016
19:20:31
Что поднять?

Roman

15.05.2016
19:33:24

Илья iHaskin E11 76, 44

15.05.2016
19:47:25

Google

Илья iHaskin E11 76, 44

15.05.2016
19:47:27

Roman

15.05.2016
20:32:06

И eoip у микротика ни с чем несовместимый

Андрей

15.05.2016
20:32:58

видел linux`овую реализацию EoIP микротиковского

Roman

15.05.2016
20:35:39
видел linux`овую реализацию EoIP микротиковского

Андрей

15.05.2016
20:37:35

Roman

15.05.2016
20:39:19

Ну да, ядрокот делал

Aleksey

16.05.2016
08:55:31

Нет так давно тема редактирования собственного сообщения поднималась. В новой версии клиента теперь можно: — Edit your messages everywhere within 2 days after posting (press the up arrow button to edit your last message).

Sergei

16.05.2016
08:59:53

проверим — точно,можно править, но стрелка вверх — не логично нифига.

Aleksey

16.05.2016
09:04:02

В скайпе стрелка вверх — удобно, мне кажется.

Sergei

16.05.2016
09:12:24

на смартфоне нет стрелок на клаве

и можно править лишь крайнюю мессагу!

Google

Sergei

16.05.2016
09:13:49

Евгений

16.05.2016
10:11:33

коллеги, нужен asr1000-rommon.154-2r.S.pkg. Есть у кого ?

Imran

16.05.2016
10:20:54

где то был, сейчас поищу

Евгений

16.05.2016
10:33:41

нужно именнно такую, хочу второй ESP постаивть и на всякий случай их по версиям выровнять

Roman

16.05.2016
10:34:38

Использует кто dpdk/netmap?

[Anonymous]

16.05.2016
11:01:28

DGS-1210-28XS/ME использовал кто? только привезли. из коробки достал, шлюз ему snmp-команду и он уходит в ребут. он и дальше себя будет так вести или исправится?

Ivan

16.05.2016
11:03:23

Шлёте команду на ребут? 🙂

[Anonymous]

16.05.2016
11:03:57

ахаха. нет. на перенастроку ipif

Petr

16.05.2016
11:14:09

то хотя бы set, у нас от get zte на аксесе бутаются)

[Anonymous]

16.05.2016
11:16:06

разобрался почему он валится. если обращаешься на несуществующий интерфейс то софт крешится и коммутатор перезагружается

прошивка последняя с форума

snmpset -v2c -c private 10.99.192.7 .1.3.6.1.2.1.16.19.11.1.1.37 a 10.99.192.7 SNMPv2-SMI::mib-2.16.19.11.1.1.37 = IpAddress: 10.99.192.7

вот так — работает. .1.3.6.1.2.1.16.19.11.1.1 это netConfigIPAddress, а 37 — видимо внутренний номер интерфейса

изменяем 37 на что нибудь другое и та же команда отправляет свичик в ребут

как то сыровато

Petr

16.05.2016
12:11:09

мб фича? лучше бутнуться чем запороть управление

[Anonymous]

16.05.2016
12:12:46

в этом случае должен прилететь Error in packet.

Google

[Anonymous]

16.05.2016
12:13:32

собственно так и происходит если задавать номера меньше чем 37. в этом случае он ругается на неправильный пакет. если 37 — выполняет команду. а если любое число больше чем 37 — ребутится 🙂

Daniil

16.05.2016
12:16:18

37, в китайской мифологии, судя по всему, проклятое числ

[Anonymous]

16.05.2016
12:18:04

К производителю не пробовал обращаться? Мб кто то еще заметил это))

[Anonymous]

16.05.2016
12:19:04

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

лучше уж проверенный DGS-3000-28SC взять

просто это была первая команда, которую я попробовал. и на не же баг. совпадение? 🙂

Sergey

16.05.2016
12:20:13

Daniil

16.05.2016
12:21:53

Главное не DGS3620

Встречаются довольно потешные баги

[Anonymous]

16.05.2016
12:23:22

критичные? что вытворяет?

Daniil

16.05.2016
12:24:25

Ну, были и критичные, к примеру проблемы с MSTP, может внезапно уйти в 100% загрузку

Petr

16.05.2016
12:24:51

да cpu вообще дохлый, немного флуда и 100%

Daniil

16.05.2016
12:25:20

Да, при выгрузке fdb по snmp может тоже уйти

Если сканить подсеть, отвечает броадкаст IP и в сегменте поднимается флуд.

Petr

16.05.2016
12:26:11

но в целом учитывая их колво на сети более менее, главное не питать много надежд)

[Anonymous]

16.05.2016
12:27:43

а по сравнению с 3627 как? пара таких есть где то

Petr

16.05.2016
12:28:26

в среднем лучше, учитывая старость

Daniil

16.05.2016
12:28:30

У нас они очень давно эксплуатируются — по мне так отличные железки

[Anonymous]

16.05.2016
12:28:37

были какие то проблемы с офсп. то ли большую таблицу не может принять то ли еще что, не помню уже. но если не насиловать слишком то работает себе потизоньку

Google

Daniil

16.05.2016
12:29:30

Ну ждать чудес тоже от него не стоит, учитывая его преклонный возраст 🙂

При определенном количестве трафика, начинаются некие ошибки, в терминологии D-Link — Buffer full drop. При это у клиентов рассыпается картинка на телевизорах

[Anonymous]

16.05.2016
12:33:17

Daniil

16.05.2016
12:36:42

везде по разному — на практике — около 4-5 гигабитах начинается

Wingman

16.05.2016
12:37:36

там, емнип, по другому: если есть линки разной ёмкости (10г и 1г, или лацпы, или 1г и сотки) — то если вниз на гиг не пролазит трафик, но на 10г аплинке начинаются дропы любого трафика — изза мелкого буфера

[Anonymous]

16.05.2016
12:40:23

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

Wingman

16.05.2016
12:40:32

[Anonymous]

16.05.2016
12:41:02

но это должен линк с меньшей пропускной спосбность уложиться в 100% получается

Wingman

16.05.2016
12:41:37

ну не обязательно, могут быть какие-то пиковые загрузки, которые даже на графиках не увидишь

Admin

[Anonymous]

16.05.2016
12:43:13

а HOL Drop 1065710 что такое? это на всех портах кроме аплинка

Wingman

16.05.2016
12:44:20

как раз чёто с этим связано, вроде как)

[Anonymous]

16.05.2016
12:50:26

по идее, помещение IPTV в приоритетную очередь должно спасти от рассыпания даже в этом случае

Wingman

16.05.2016
12:50:35

[Anonymous]

16.05.2016
12:50:36

т.к. такие очереди опустошаются первыми

Wingman

16.05.2016
12:50:38

[Anonymous]

16.05.2016
12:52:21

1,8 Гб в пике там. QoS настроен. пока никто не жалуется. может если до 4-5 дойдет, то будет заметно, но это будет в том районе не скоро

Евгений

16.05.2016
13:00:32

купите Panasonic KX-TDA100 🙂 5 лет не включали

Sergey

16.05.2016
13:03:08

10G интерфейс у ней есть?

Google

Wingman

16.05.2016
13:04:05

купите hp microserver G7 =)

[Anonymous]

16.05.2016
13:06:32
купите Panasonic KX-TDA100 🙂 5 лет не включали

Евгений

16.05.2016
13:07:15

выкинуть жаль 🙂 включать не будем уже точно 🙂

[Anonymous]

16.05.2016
13:16:28

а я понял было что купили и побоялись включить. и лежит 5 лет без дела)

Ant

16.05.2016
13:19:07

один маленький щелчок выключателем, и целый вал ответственности для щёлкающего

Евгений

16.05.2016
13:21:38

да мы ей в свое время нащелкались 🙂

Aleksey

16.05.2016
14:34:32

Народ, а кто-нибудь может связывался с DECT-базами, к которым можно было бы подключить внешние антенны? Если она цепляется к АТС по SIP через Ethernet, вообще хорошо.

? Stan

Buffer full drop что это

Уверен, у него проц не более 600-800Мгц, и скорее 1 ядро всего, если запросы летят напрямую к цпу ( широковещалки броадкаста или еще какая дрянь ) то в лучшем случае он будет заметно плохо жевать трафик, в худшем повесится, и скорее повесится еще и от перегрева.

Увы я уважаю только среднецоновой и выше сегмент микротик, циско, джунипер или полноценный боард сервер на линукс etc., с нормальными сетевыми.
Линксис — огрызок циски, не более.

Отправлено спустя 1 минуту 15 секунд:

А по arp -a выдаёт 11 адресов.

тут бы глянуть что от них летит еще

Отправлено спустя 3 минуты 16 секунд:
Попросите КЦ провайдера соединить с тех.отделом.
Тех.отдел попросите переселить вас в другой сегмент сети, зачастую в другой VID, сообщите то что описали тут.
Как подтвердят что сделали — пробейте снова arp -a, гляньте правда ли, или врут.
Если выполнили требования — наблюдайте за инетом.
Самый простой способ проверить что не так, если поддержка у провайдера адекватна.

Отправлено спустя 7 минут 18 секунд:
Ах да, еще момент, вы уверены что вешается роутер не от вашего ПК?
Банальная проверка на вирусню с помощью cureit!, и сброс сетевого стека, в командной строке:
netsh winsock reset
netsh int ip reset

Думаю не повредят, только после команд настроек на сетевой не будет, так что если у вас статический IP их следует записать.

Евгений King:
papamama: Уверены, что linksys слабенький роутер?
Уверен, у него проц не более 600-800Мгц, и скорее 1 ядро всего
Да, всё так, проц Marvell 88F6282 800 МГц

Евгений King: Попросите КЦ провайдера соединить с тех.отделом.
Тех.отдел попросите переселить вас в другой сегмент сети, зачастую в другой VID, сообщите то что описали тут.

Кстати, у соседа и друга интернет от киестара и у обоих белый айпишник, и на всег 3 роутерах у обоих норм (да-да все 3 роутера носил:)).

papamama
Кабель соединяющий роутер и комп исправен?
Ну ткну пальцем в небо.
Возможно, проблема в том, что на оборудовании провайдера каким-то чудом выставлены настройки порта принудительно на 1 Гбит/с. ТП-Линки не могут поднять свой порт на такой скорости (гигабита там нет ), а Циска по какой-то причине, не может согласоваться с оборудованием провайдера (так сложились звезды). И тут начинаются чудеса.
Соответственно, при подключении напрямую, умная Винда применяет корректные настройки скорости и дуплекса.

Может ли компьютер (его сетевая карта) как-то влиять на роутер?

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

Евгений King: Отправлено спустя 7 минут 18 секунд:
Ах да, еще момент, вы уверены что вешается роутер не от вашего ПК?
Банальная проверка на вирусню с помощью cureit!, и сброс сетевого стека, в командной строке:
netsh winsock reset
netsh int ip reset

Да, я кстати об этом спросил в первом посте — может ли комп вешать роутер? Вирусня вряд ли, т.к. система практически новая + премиум антивирус. Может ли что-то ещё в компе (сетевая, брандмауер и т.д.) вешать роутер?

Звідки: Казна-де

papamama: Помогите, пожалуйста, разобраться со следующей проблемой.

При подключении lan-кабеля в роутер (интернет > роутер > компьютер по кабелю), периодически пропадает интернет, на стороне провайдера видны ошибки и т.д., на какое-то время помогает перезагрузка роутера.

Какие ошибки?
Для понимания:
CRC Error 7 Excessive Deferral 0
Undersize 0 CRC Error 0
Oversize 0 Late Collision 0
Fragment 1 Excessive Collision 0
Jabber 0 Single Collision 0
Symbol Error 4 Collision 0
Buffer Full Drop 101629 STP Drop 18065
ACL Drop 0 HOL Drop 0
Multicast Drop 0
VLAN Ingress Drop 22332842
Invalid IPv6 0
STP Drop 6595
Storm and FDB Discard 0
MTU Drop 0

Вот их сколько разных, и это только малая капля на недосвитче Dlink, стянул с первого попавшегося под руку коммутатора статистику рандомного порта.
Самые распространенные:
CRC — ошибки контрольной суммы, пакеты бьются не долетая к вас/ от вас
Fragment — то же самое, но когда идет дробление больших пакетов на более мелкие, мало вероятно
Collision — столкновение пакетов из-за несогласованности меж отправитиелем и получателем
acl drop — отброс пакета согласно установленных «правил» свитча, это настройка провайдера
STP drop — дропы лишних stp пакетов, когда STP выключен, или пакеты STP не распознаны
Storm and FDB Discard — дропы согласно встроенных механизмов защиты коммутатора от шторма и петли
MTU drop — дропы из-за несогласованности MTU

Так вот, если прут CRC, Fragment, Collision, просим провайдера проверить длину и целостность кабеля, при наличии норм коммутаторов они это могут, и просим назвать сколько.
Если кабеля больше 70м, не исключено что просто не пробивает, или плохой кабель, просим заменить

Отправлено спустя 1 минуту 37 секунд:
У меня все, пойду есть людей

DBA: когда пасует VACUUM — чистим таблицу вручную

VACUUM может «зачистить» из таблицы в PostgreSQL только то, что никто не может увидеть — то есть нет ни одного активного запроса, стартовавшего раньше, чем эти записи были изменены.

А если такой неприятный тип (продолжительная OLAP-нагрузка на OLTP-базе) все же есть? Как почистить активно меняющуюся таблицу в окружении длинных запросов и не наступить на грабли?

Раскладываем грабли

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

Обычно такая ситуация случается на относительно небольшой таблице, но в которой происходит очень много изменений. Обычно это или разные счетчики/агрегаты/рейтинги, на которых часто-часто выполняется UPDATE, или буфер-очередь для обработки какого-то постоянно идущего потока событий, записи о которых все время INSERT/DELETE.

Попробуем воспроизвести вариант с рейтингами:

CREATE TABLE tbl(k text PRIMARY KEY, v integer); CREATE INDEX ON tbl(v DESC); -- по этому индексу будем строить рейтинг INSERT INTO tbl SELECT chr(ascii('a'::text) + i) k , 0 v FROM generate_series(0, 25) i;

А параллельно, в другом соединении, стартует долгий-долгий запрос, собирающий какую-то сложную статистику, но не затрагивающий нашей таблицы:

SELECT pg_sleep(10000);

Теперь мы много-много раз обновляем значение одного из счетчиков. Для чистоты эксперимента сделаем это в отдельных транзакциях с помощью dblink, как это будет происходить в реальности:

DO $$ DECLARE i integer; tsb timestamp; tse timestamp; d double precision; BEGIN PERFORM dblink_connect('dbname=' || current_database() || ' port=' || current_setting('port')); FOR i IN 1..10000 LOOP tsb = clock_timestamp(); PERFORM dblink($e$UPDATE tbl SET v = v + 1 WHERE k = 'a';$e$); tse = clock_timestamp(); IF i % 1000 = 0 THEN d = (extract('epoch' from tse) - extract('epoch' from tsb)) * 1000; RAISE NOTICE 'i = %, exectime = %', lpad(i::text, 5), lpad(d::text, 5); END IF; END LOOP; PERFORM dblink_disconnect(); END; $$ LANGUAGE plpgsql;

NOTICE: i = 1000, exectime = 0.524 NOTICE: i = 2000, exectime = 0.739 NOTICE: i = 3000, exectime = 1.188 NOTICE: i = 4000, exectime = 2.508 NOTICE: i = 5000, exectime = 1.791 NOTICE: i = 6000, exectime = 2.658 NOTICE: i = 7000, exectime = 2.318 NOTICE: i = 8000, exectime = 2.572 NOTICE: i = 9000, exectime = 2.929 NOTICE: i = 10000, exectime = 3.808

Что же произошло? Почему даже для простейшего UPDATE единственной записи время выполнения деградировало в 7 раз — с 0.524ms до 3.808ms? Да и рейтинг наш строится все медленнее и медленнее.

Во всем виноват MVCC

Все дело в механизме MVCC, который заставляет запрос просматривать все предыдущие версии записи. Так давайте почистим нашу таблицу от «мертвых» версий:

VACUUM VERBOSE tbl;

INFO: vacuuming "public.tbl" INFO: "tbl": found 0 removable, 10026 nonremovable row versions in 45 out of 45 pages DETAIL: 10000 dead row versions cannot be removed yet, oldest xmin: 597439602

Ой, а чистить-то и нечего! Параллельно выполняющийся запрос нам мешает — ведь он когда-то может захотеть обратиться к этим версиям (а вдруг?), и они должны быть ему доступны. И поэтому даже VACUUM FULL нам не поможет.

«Схлапываем» таблицу

Но мы-то точно знаем, что тому запросу наша таблица не нужна. Поэтому попробуем все-таки вернуть производительность системы в адекватные рамки, выкинув из таблицы все лишнее — хотя бы и «вручную», раз VACUUM пасует.

Чтобы было нагляднее, рассмотрим уже на примере случая таблицы-буфера. То есть идет большой поток INSERT/DELETE, и иногда в таблице оказывается вообще пусто. Но если там не пусто, мы должны сохранить ее текущее содержимое.

#0: Оцениваем ситуацию

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

Сформулируем критерии — «уже пора действовать», если:

VACUUM запускался достаточно давно
Нагрузку ожидаем большую, поэтому пусть это будет 60 секунд с последнего [auto]VACUUM.
физический размер таблицы больше целевого
Определим его как удвоенное количество страниц (блоков по 8KB) относительно минимального размера — 1 blk на heap + 1 blk на каждый из индексов — для потенциально-пустой таблицы. Если же мы ожидаем, что в буфере «штатно» будет всегда оставаться некоторый объем данных, эту формулу разумно подтюнить.

Проверочный запрос

SELECT relpages , (( SELECT count(*) FROM pg_index WHERE indrelid = cl.oid ) + 1)


relpages | size_norm | size | vaclag ------------------------------------------- 0 | 24576 | 1105920 | 3392.484835
#1: Все равно VACUUM
Мы не можем знать заранее, сильно ли нам мешает параллельный запрос — сколько именно записей «устарело» с момента его начала. Поэтому, когда все-таки решим таблицу как-то обработать, по-любому сначала стоит выполнить на ней VACUUM — он, в отличие от VACUUM FULL, параллельным процессам работать с данными на чтение-запись не мешает.
Заодно он может сразу вычистить большую часть того, что мы хотели бы убрать. Да и последующие запросы по этой таблице пойдут у нас по «горячему кэшу», что сократит их продолжительность — а, значит, и суммарное время блокировки других нашей обслуживающей транзакцией.
#2: Есть кто-нибудь дома?
Давайте проверим — есть ли в таблице вообще хоть что-то:
TABLE tbl LIMIT 1;
Если не осталось ни единой записи, то мы можем сильно сэкономить на обработке — просто выполнив TRUNCATE:
Она действует так же, как безусловная команда DELETE для каждой таблицы, но гораздо быстрее, так как она фактически не сканирует таблицы. Более того, она немедленно высвобождает дисковое пространство, так что выполнять операцию VACUUM после неё не требуется.
Надо ли вам при этом сбрасывать счетчик последовательности таблицы (RESTART IDENTITY) — решайте сами.
#3: Все — по-очереди!
Поскольку мы работаем в условиях высокой конкурентности, то пока мы тут проверяем отсутствие записей в таблице, кто-то мог туда уже что-то записать. Потерять эту информацию мы не должны, значит — что? Правильно, надо сделать, чтобы никто уж точно записать не мог.
Для этого нам необходимо включить SERIALIZABLE-изоляцию для нашей транзакции (да, тут мы стартуем транзакцию) и заблокировать таблицу «намертво»:
BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; LOCK TABLE tbl IN ACCESS EXCLUSIVE MODE;
Именно такой уровень блокировки обусловлен теми операциями, которые мы хотим над ней производить.
#4: Конфликт интересов
Мы тут приходим и хотим табличку «залочить» — а если на ней в этот момент кто-то был активен, например, читал из нее? Мы «повиснем» в ожидании освобождения этой блокировки, а другие желающие почитать упрутся уже в нас…
Чтобы такого не произошло, «пожертвуем собой» — если уж за определенное (допустимо малое) время блокировку нам получить все-таки не удалось, то мы получим от базы exception, но хотя бы не помешаем сильно остальным.
Для этого выставим переменную сессии lock_timeout (для версий 9.3+) или/и statement_timeout. Главное помнить, что значение statement_timeout применяется только со следующего statement. То есть вот так в склейке — не заработает:
SET statement_timeout = . ;LOCK TABLE . ;
Чтобы не заниматься потом восстановлением «старого» значения переменной, используем форму SET LOCAL, которая ограничивает область действия настройки текущей транзакцией.
Помним, что statement_timeout распространяется на все последующие запросы, чтобы транзакция не могла у нас растянуться до неприемлемых величин, если данных в таблице таки окажется много.
#5: Копируем данные
Если таблица оказалась не совсем пустая — данные придется пересохранять через вспомогательную временную табличку:
CREATE TEMPORARY TABLE _tmp_swap ON COMMIT DROP AS TABLE tbl; 
Сигнатура ON COMMIT DROP означает, что в момент окончания транзакции временная таблица перестанет существовать, и заниматься ее ручным удалением в контексте соединения не нужно.
Поскольку мы предполагаем, что «живых» данных не очень много, то эта операция должна пройти достаточно быстро.
Ну вот как бы и все! Не забывайте после завершения транзакции запустить ANALYZE для нормализации статистики таблицы, если это необходимо.
Собираем итоговый скрипт
Используем такой «псевдопитон»:
# собираем статистику с таблицы stat 2 * stat.size_norm and stat.vaclag is None or stat.vaclag > 60: -> VACUUM %table; try: -> BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; # пытаемся захватить монопольную блокировку с предельным временем ожидания 1s -> SET LOCAL statement_timeout = '1s'; SET LOCAL lock_timeout = '1s'; -> LOCK TABLE %table IN ACCESS EXCLUSIVE MODE; # надо убедиться в пустоте таблицы внутри транзакции с блокировкой row TRUNCATE TABLE %table RESTART IDENTITY; else: # создаем временную таблицу с данными таблицы-оригинала -> CREATE TEMPORARY TABLE _tmp_swap ON COMMIT DROP AS TABLE %table; # очищаем оригинал без сброса последовательности -> TRUNCATE TABLE %table; # вставляем все сохраненные во временной таблице данные обратно -> INSERT INTO %table TABLE _tmp_swap; -> COMMIT; except Exception as e: # если мы получили ошибку, но соединение все еще "живо" - словили таймаут if not isinstance(e, InterfaceError): -> ROLLBACK;
А можно не копировать данные второй раз?
В принципе, можно, если на oid самой таблицы не завязаны какие-то другие активности со стороны БЛ или FK со стороны БД: 
CREATE TABLE _swap_%table(LIKE %table INCLUDING ALL); INSERT INTO _swap_%table TABLE %table; DROP TABLE %table; ALTER TABLE _swap_%table RENAME TO %table;
Прогоним скрипт на исходной таблице и проверим метрики: 
VACUUM tbl; BEGIN TRANSACTION ISOLATION LEVEL SERIALIZABLE; SET LOCAL statement_timeout = '1s'; SET LOCAL lock_timeout = '1s'; LOCK TABLE tbl IN ACCESS EXCLUSIVE MODE; CREATE TEMPORARY TABLE _tmp_swap ON COMMIT DROP AS TABLE tbl; TRUNCATE TABLE tbl; INSERT INTO tbl TABLE _tmp_swap; COMMIT;
relpages | size_norm | size | vaclag ------------------------------------------- 0 | 24576 | 49152 | 32.705771


Похожие публикации:

Adobe after effects сколько весит
Как выйти из visudo
Как изменить цвет картинки при наведении css
Как сделать gui в роблокс студио

Buffer full drop что это

Buffer full drop что это

Buffer full drop что это

Buffer full drop что это

DBA: когда пасует VACUUM — чистим таблицу вручную

Раскладываем грабли

Во всем виноват MVCC

«Схлапываем» таблицу

#0: Оцениваем ситуацию

#1: Все равно VACUUM

#2: Есть кто-нибудь дома?

#3: Все — по-очереди!

#4: Конфликт интересов

#5: Копируем данные

Собираем итоговый скрипт

Добавить комментарий Отменить ответ