ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix sweep висит по 10 часов
25 сообщений из 89, страница 2 из 4
  2  все
gfix sweep висит по 10 часов
    #40019293
Softologic
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Softologic
Гость
fraks
tromani
Dimitry Sibiryakov,
везде любой запрос начинается со starttransaction и заканчивается commit/rollback


Выполните запрос на рабочей базе и посмотрите как и все ли транзакции у вас заканчиваются.
Запрос написан для Fibrebird-2.5 не гарантирую что на тройке будет работать.

Транзакция у которой MON$TRANSACTION_ID = OLDEST TRANSACTION - и есть та самая которая не дает собирать мусор.

 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
-- FrmFirebird.QTrans
--
-- Текущие транзакции в базе
--

select
  tr.MON$TRANSACTION_ID     as MON$TRANSACTION_ID,
  tr.MON$ATTACHMENT_ID      as MON$ATTACHMENT_ID,

  att.MON$REMOTE_ADDRESS    as att_ip,
  att.MON$REMOTE_PROCESS    as att_exe,

  -- выкусить текст после последнего слэша, и в верхний регистр
  upper( reverse( substring( reverse(att.MON$REMOTE_PROCESS) from 1 for position('\', reverse(replace(att.MON$REMOTE_PROCESS,'/','\')), 1)-1 ) ) )
                            as att_exe2,

  case tr.MON$STATE
    when 0 then 'idle'
    when 1 then 'active'
    else        tr.MON$STATE
  end                       as state,

  tr.MON$TIMESTAMP          as timestamp_,
  tr.MON$TOP_TRANSACTION    as top_transaction,
  tr.MON$OLDEST_TRANSACTION as oldest_transaction,
  tr.MON$OLDEST_ACTIVE      as oldest_active,

  case tr.MON$ISOLATION_MODE
    when 0 then 'consistency'
    when 1 then 'concurrency'
    when 2 then 'RC record version'
    when 3 then 'RC no record version'
    else        tr.MON$ISOLATION_MODE
  end                       as isolation_mode,

  case tr.MON$LOCK_TIMEOUT
    when -1 then 'wait'
    when  0 then 'no wait'
    else         'timeout ' || tr.MON$LOCK_TIMEOUT
  end                       as lock_timeout,

  tr.MON$READ_ONLY          as read_only,
  tr.MON$AUTO_COMMIT        as auto_commit,
  tr.MON$AUTO_UNDO          as auto_undo,
  tr.MON$STAT_ID            as MON$STAT_ID,

  -- сколько часов коннект существует
  (datediff(HOUR,   tr.MON$TIMESTAMP, current_timestamp)) as dt_hour,

  -- сколько минут коннект существует
  (datediff(MINUTE, tr.MON$TIMESTAMP, current_timestamp)) as dt_minute,

  -- если транзакция (или коннект?) активен более 180 минут (3 часа) - выделим его красным шрифтом
  iif((datediff(MINUTE, tr.MON$TIMESTAMP, current_timestamp)) > 180, 'RED', '') as ROW_COLOR

from mon$transactions tr
  left join mon$attachments att on (att.mon$attachment_id =  tr.MON$ATTACHMENT_ID)

order by tr.MON$TIMESTAMP





Вот так можно посмотреть какие запросы были выполнены в этой транзакции

 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
-- FrmFirebird.QStat
--
-- Запросы в указанной транзакции
--

select
  st.MON$STATEMENT_ID       as MON$STATEMENT_ID,
  st.MON$ATTACHMENT_ID      as MON$ATTACHMENT_ID,
  st.MON$TRANSACTION_ID     as MON$TRANSACTION_ID,

  att.MON$REMOTE_ADDRESS    as att_ip,
  att.MON$REMOTE_PROCESS    as att_exe,

  case st.MON$STATE
    when 0 then 'idle'
    when 1 then 'active'
    when 2 then 'stalled'
    else        st.MON$STATE
  end                       as STATE,

  st.MON$TIMESTAMP          as TIMESTAMP_,

  -- сколько минут запрос существует
  (datediff(MINUTE, st.MON$TIMESTAMP, current_timestamp)) as dt_minute,

  st.MON$STAT_ID            as MON$STAT_ID

from mon$statements st
  left join mon$attachments att on (att.mon$attachment_id =  st.MON$ATTACHMENT_ID)

where (st.MON$TRANSACTION_ID = :TRANSACTION_ID)

order by 
  st.MON$STATEMENT_ID






А вот так глянуть на сам текст запроса

 
Код: plsql
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
-- FrmFirebird.QStatSQL
--
-- Текст указанного запроса
--

select 
  mon$sql_text

from mon$statements

where (mon$statement_id = :statement_id)




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

Респект. Мастхевные запросы!
...
Рейтинг: 0 / 0
17.11.2020, 10:55
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019301
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
fraks,

спасибо добрый человек за запросы, будем тыкать
...
Рейтинг: 0 / 0
17.11.2020, 11:12
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019305
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
tromani,

горе, ты статистику смогло снять ? Бекап сделать ? Или сервер виноват ? :)
...
Рейтинг: 0 / 0
17.11.2020, 11:20
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019307
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
hvlad,

да щастье мое, усе сделал, программистов потыкал
...
Рейтинг: 0 / 0
17.11.2020, 11:23
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019336
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
tromani,

разобрались что вешало
суть вот в чем: есть таблица1 которая много и часто обновляется
и есть запрос который выводит некую сводную по этой таблице суммирует данные и т.д. а результат в DBGrid
в которой участвуют записи от первой до последней из таблицы1

так вот, и последний вопрос в каком режиме запустить транзакцию этого запроса чтоб оно выполнилось и не плодила версий даже если после этого некоторый данные в таблице1 изменятся? или в контексте DBGrid и компонентов IB вопрос не имеет смысла?
...
Рейтинг: 0 / 0
17.11.2020, 11:57
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019342
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
tromani,

до 4.0 запускай в транзакции с режимом изолированности Read Committed Read Only. Правда результат может быть не совсем верным для отчётов с агрегатами пока лучше использовать SNAPSHOT, а он будет удерживать версии.

Ну или делай commit сразу после построения отчёта, правда в этом случае надо использовать кеширующие датасеты которые не закрываются по commit, или вообще не используй DbGrid и DataSet в этом месте
...
Рейтинг: 0 / 0
17.11.2020, 12:05
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019392
Ivan_Pisarevsky
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ivan_Pisarevsky
Участник
Как вариант набирать в снапшоте данные в GTT коммититиь сразу после набора и до посинения елозить по ГТТ, с фильтрами, ДВ компонентами и прочими блэкджеком и ...
...
Рейтинг: 0 / 0
17.11.2020, 13:30
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019409
Фотография kdv
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
kdv
Участник
вы зря пишете советы по поводу оптимизации софта.
Тут вопросы задает админ. А где-то там, "во глубине ... руд", сидят разрабы этого счастья, и сюда они 100% не ходят.
Классическая ситуация.
К нам регулярно обращаются конторы-юзеры, и когда мы киваем на их вендоров, вендоры уходят в глубокое шифрование.
Видимо, "такое" им нафиг не надо.
...
Рейтинг: 0 / 0
17.11.2020, 13:48
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019414
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
kdvТут вопросы задает админ. А где-то там, "во глубине ... руд", сидят разрабы этого счастья,
и сюда они 100% не ходят. Классическая ситуация.

А по-моему в данном случае наоборот: топикстартер как раз и есть архитектор и разработчик
в одном лице, а админ отсутствует как класс. Это если судить по его реакции на советы
использовать "-g" и отпинать разработчиков.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
17.11.2020, 14:02
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019448
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
Dimitry Sibiryakov,

я архитектор и админ по вынужденности, хотя от админа у меня мало опыта, у вас конечно тут подход что на любой проект мало-мальский только на одну БД надо 17 человек это ж не везде возможно, посоветуете аутсорсинговый сервис по админке фаябердных бд с саппортом 24/7 и за небольшие деньги? вот и я не знаю, приходится админить то что наархитектил
...
Рейтинг: 0 / 0
17.11.2020, 14:30
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019453
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
Gstat execution time Tue Nov 17 14:16:37 2020

Database header page information:
Flags 0
Generation 16438551
System Change Number 0
Page size 16384
ODS version 12.0
Oldest transaction 2728724
Oldest active 2728725
Oldest snapshot 2728725
Next transaction 16420357
Sequence number 0
Next attachment ID 77647
Implementation HW=AMD/Intel/x64 little-endian OS=Windows CC=MSV
C
Shadow count 0
Page buffers 0
Next header page 0
Database dialect 3
Creation date Nov 17, 2020 9:07:26
Attributes force write

Variable header data:
Sweep interval: 20000
*END*


Database file sequence:
File C:\BASES\LF\STORAGE.FDB is the only file

Analyzing database pages ...
POOLBETS (149)
Primary pointer page: 274, Index root page: 275
Total formats: 1, used formats: 1
Average record length: 74.10, total records: 710742
Average version length: 9.00, total versions: 5595281, max versions: 7433
Average fragment length: 7.32, total fragments: 271, max fragments: 1
Average unpacked length: 214.00, compression ratio: 2.89
Pointer pages: 5, data page slots: 14824
Data pages: 14824, average fill: 87%
Primary pages: 4997, secondary pages: 9827, swept pages: 4778
Empty pages: 7, full pages: 14815
Fill distribution:
0 - 19% = 8
20 - 39% = 0
40 - 59% = 0
60 - 79% = 3936
80 - 99% = 10880

Index PK_POOLBETS (0)
Root page: 103484, depth: 2, leaf buckets: 259, nodes: 710742
Average node length: 5.89, total dup: 0, max dup: 0
Average key length: 3.00, compression ratio: 1.32
Average prefix length: 2.95, average data length: 1.00
Clustering factor: 13934, ratio: 0.02
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 258

Index POOLBETS_IDX1 (1)
Root page: 103743, depth: 2, leaf buckets: 222, nodes: 710742
Average node length: 5.04, total dup: 627337, max dup: 49
Average key length: 2.15, compression ratio: 1.84
Average prefix length: 3.82, average data length: 0.13
Clustering factor: 46284, ratio: 0.07
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 0
80 - 99% = 221

Index POOLBETS_IDX2 (2)
Root page: 103965, depth: 2, leaf buckets: 218, nodes: 710742
Average node length: 4.89, total dup: 710736, max dup: 608970
Average key length: 2.00, compression ratio: 0.57
Average prefix length: 1.14, average data length: 0.00
Clustering factor: 16348, ratio: 0.02
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 7
60 - 79% = 1
80 - 99% = 210

Index POOLBETS_IDX3 (3)
Root page: 104180, depth: 2, leaf buckets: 234, nodes: 710742
Average node length: 4.91, total dup: 708562, max dup: 38795
Average key length: 2.02, compression ratio: 6.29
Average prefix length: 12.69, average data length: 0.02
Clustering factor: 51260, ratio: 0.07
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 37
60 - 79% = 2
80 - 99% = 195

Index POOLBETS_IDX4 (4)
Root page: 104396, depth: 2, leaf buckets: 215, nodes: 710742
Average node length: 4.89, total dup: 710740, max dup: 572639
Average key length: 2.00, compression ratio: 0.90
Average prefix length: 1.81, average data length: 0.00
Clustering factor: 9798, ratio: 0.01
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 1
60 - 79% = 1
80 - 99% = 213

Index POOLBETS_IDX5 (5)
Root page: 104611, depth: 2, leaf buckets: 217, nodes: 711504
Average node length: 4.89, total dup: 711499, max dup: 354429
Average key length: 2.00, compression ratio: 1.00
Average prefix length: 2.00, average data length: 0.00
Clustering factor: 11229, ratio: 0.02
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 5
60 - 79% = 1
80 - 99% = 211

Index POOLBETS_IDX6 (6)
Root page: 104826, depth: 2, leaf buckets: 371, nodes: 710742
Average node length: 4.89, total dup: 709648, max dup: 3314
Average key length: 2.00, compression ratio: 1.50
Average prefix length: 2.99, average data length: 0.00
Clustering factor: 581020, ratio: 0.82
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 314
60 - 79% = 0
80 - 99% = 57

Index POOLBETS_IDX7 (7)
Root page: 105041, depth: 2, leaf buckets: 395, nodes: 710742
Average node length: 8.61, total dup: 3152, max dup: 14
Average key length: 5.73, compression ratio: 1.78
Average prefix length: 7.42, average data length: 2.76
Clustering factor: 124409, ratio: 0.18
Fill distribution:
0 - 19% = 0
20 - 39% = 0
40 - 59% = 31
60 - 79% = 1
80 - 99% = 363

Gstat completion time Tue Nov 17 14:17:38 2020

на данный момент вот так? это норм или все плохо?
...
Рейтинг: 0 / 0
17.11.2020, 14:33
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019462
Dimitry Sibiryakov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Dimitry Sibiryakov
Участник
tromaniэто норм или все плохо?

Терминальная стадия. Это не лечится, переходи на другую СУБД.
Posted via ActualForum NNTP Server 1.5
...
Рейтинг: 0 / 0
17.11.2020, 14:40
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019475
Фотография Симонов Денис
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Симонов Денис
Участник
tromani,

плохо, версий на несколько порядков больше чем количество записей. Самая длинная цепочка версий ~7000. То есть мусор не собирается. А когда начнёт собираться всё встанет колом, ибо ещё кучу индексов навешено.
Не удивительно что оно тормозит. Свип так и не отработал b/r вы тоже не сделали.

Либо меняйте архитектуру приложения, либо переходите на Firebird 4.0, там оно хоть как-то дышать сможет.

Как я уже говорил относительно безболезненно можно активной держать RC RO транзакцию, в других режимах изолированности будет копиться мусор. Или найди способ сделать читающую транзакцию короткой.

UPDATE лучше заменить на INSERT. Лучше иметь много записей, чем мало, но с гигантским количеством версий. Если есть возможность прикрутить хранимые агрегаты.
...
Рейтинг: 0 / 0
17.11.2020, 14:58
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019479
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
Симонов Денис,

это после свипа и б/р поработало 4 часа
...
Рейтинг: 0 / 0
17.11.2020, 15:02
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019514
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дегтярев Евгений
Участник
авторда там очень быстрый поток данных и сильно меняющийся во времени
автор 250 миллионов транзакций за четыре дня
в среднем 700+ транзакций/сек
если это все льется через один инстанс, есть смысл агрегировать данные и фиксировать пачками в одной транзакции, например раз в сек
если переписываются одни и теже ключи по нескольку раз, то интервал можно увеличить
опять же если все делает один инстанс, то и сводные данные можно на нем считать и забирать с него же
...
Рейтинг: 0 / 0
17.11.2020, 15:33
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019523
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
tromani
Oldest transaction 2728724
Oldest active 2728725
Oldest snapshot 2728725
Next transaction 16420357
Найди Oldest active, выясни какого она так долго живёт и исправляй ситуацию.

tromani
Average record length: 74.10, total records: 710742
Average version length: 9.00, total versions: 5595281, max versions: 7433
...
Primary pages: 4997, secondary pages: 9827, swept pages: 4778
Бэкверсий в 8 раз больше, чем записей, но основная часть первичных версий не менялась (или мусор собран).
Судя по всему, какая-то небольшая часть записей интенсивно обновляется на фоне долго играющих тр-ций и в них накапливаются очень длинные цепочки версий - 7433 это очень много.
8 индексов, правда, весьма небольших.

Я бы увеличил кеш БД хотя бы до 20К страниц для начала.
Ну и избавляться от долгоиграющих тр-ций или переводить их в режим RC RO, если возможно.
...
Рейтинг: 0 / 0
17.11.2020, 15:44
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019547
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
hvlad,

о спасибо я хоть понял че куда смотреть, последний час воздействие волшебного пинания привело к тому что max versions: 1-4 держится а всего 80-90
...
Рейтинг: 0 / 0
17.11.2020, 16:27
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019564
alekcvp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
alekcvp
Участник
hvlad
Найди Oldest active, выясни какого она так долго живёт и исправляй ситуацию.

А при отключении от базы всех клиентов, все транзакции прибиваются автоматом?..
...
Рейтинг: 0 / 0
17.11.2020, 16:51
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019606
fraks
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
fraks
Участник
Интересуюсь у топикстартера - какова сама исходная задача?
Откуда столько данных, что за данные, почему нужно пихать это в базу?

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

Если таки не отходить от DB_Aware то придется использовать кеширующие датасеты.

Я еще во времена D2 забил на все эти DB-Aware, данные получаю через компоненты которые не являются датасетом, сразу выгребаю их в свой буфер, закрываю транзакцию и дальше пялюсь сколько угодно, хоть вообще от базы отцепляйся. Хотим освежить данные - жмем F5, вызывается опять запрос, очищает буфер, заливает в него новые данные, репозиционируемся в нем, если нужно. Ну или какая иная операция потребует обновления данных.
...
Рейтинг: 0 / 0
17.11.2020, 17:56
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019616
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
fraks,

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

ЗЫ. Ну т.е. начальство смотрело отчет и оставляло его висеть часов 10 а за это время там все обновлялось и обновлялось
...
Рейтинг: 0 / 0
17.11.2020, 18:14
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019617
hvlad
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
hvlad
Участник
alekcvp
А при отключении от базы всех клиентов, все транзакции прибиваются автоматом?..
Не, они продолжают вводить данные :)
Конечно прибиваются, но не автоматом, а роллбеком.
...
Рейтинг: 0 / 0
17.11.2020, 18:15
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019665
Фотография Дегтярев Евгений
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Дегтярев Евгений
Участник
tromani
данные вносятся беспрерывно 150-200 клиентами

что это за роботы, которые таким небольшим вол-вом генерят тысячу транзакций в сек?
...
Рейтинг: 0 / 0
17.11.2020, 20:14
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019694
tromani
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
tromani
Гость
Дегтярев Евгений,

ой, о таком не говорят в приличном обществе) там боты
...
Рейтинг: 0 / 0
17.11.2020, 21:33
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019720
Vlad F
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Vlad F
Участник
tromani,

Боты, имхо, еще не приговор. Но, как правило, признак финансирования.
Вы не подумывали о профессиональной поддержке вашего решения силами специалистов?
Ведь она у FB сообщества есть. Причем, кмк, достаточно приличная.
...
Рейтинг: 0 / 0
17.11.2020, 22:50
| Ответить | Цитировать | Написать  
gfix sweep висит по 10 часов
    #40019722
Фотография Старый плюшевый мишка
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Старый плюшевый мишка
Участник
Vlad F
tromani,

Боты, имхо, еще не приговор. Но, как правило, признак финансирования.
Вы не подумывали о профессиональной поддержке вашего решения силами специалистов?
Ведь она у FB сообщества есть. Причем, кмк, достаточно приличная.


Да ладно, сам научится. Если начнёт учиться, а не гоношиться с пинанием разработчиков FB ;) Но это я так, брюзжу, он, я так думаю, уже и сам понял :)
...
Рейтинг: 0 / 0
17.11.2020, 23:04
| Ответить | Цитировать | Написать  
25 сообщений из 89, страница 2 из 4
  2  все
Форумы / Firebird, InterBase [игнор отключен] [закрыт для гостей] / gfix sweep висит по 10 часов
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=40&msg=40019694&tid=1560184]:
 0ms
get settings:
 9ms
get forum list:
 14ms
check forum access:
 4ms
check topic access:
 4ms
track hit:
 59ms
get topic data:
 11ms
get forum data:
 3ms
get page messages:
 70ms
get tp. blocked users:
 2ms
others: 247ms
total:  423ms
созд. / загр.: 423ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]