| Начало » Использование СУБД » Firebird, HQbird, InterBase » FB 5.0 Производительность, оптимизация Переход к форуму:
	| 
		
			| FB 5.0 Производительность, оптимизация [сообщение #4716] | Thu, 28 March 2024 15:19  |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| Вот такая фигня. 
 Оптимизация заключалась в выкидывании из запроса мастер таблицы, т.к. в след. джойне было условие 1:1 по FK
 подготовка данных - заливка во временные таблицы - 18 сек. одинаково.
 
 выборка из временных таблиц - через execute stmt
 
 
 "FB50 not Optimized"1 record(s) was(were) inserted into LOG_EVENTS
 26 record(s) was(were) inserted into TMP$ATTRIBUTES
 26536 record(s) was(were) inserted into TMP$ITEMS
 563640 record(s) was(were) inserted into TMP$VALUES
 70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
 2 record(s) was(were) inserted into TMP$DIMENSIONS
 26536 record(s) was(were) inserted into TMP$FACTS
 1 record(s) was(were) inserted into STAT$REPORTS
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 2m 1s 140ms
 Avg fetch time = 62,73 ms
 Current memory = 1 688 768 688
 Max memory = 1 720 519 616
 Memory buffers = 99 999
 Reads from disk to cache = 3 261
 Writes from cache to disk = 1 486
 Fetches from cache = 290 453 657
 
 "FB50  Optimized"
 1 record(s) was(were) inserted into LOG_EVENTS
 26 record(s) was(were) inserted into TMP$ATTRIBUTES
 26536 record(s) was(were) inserted into TMP$ITEMS
 563640 record(s) was(were) inserted into TMP$VALUES
 70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
 2 record(s) was(were) inserted into TMP$DIMENSIONS
 26536 record(s) was(were) inserted into TMP$FACTS
 1 record(s) was(were) inserted into STAT$REPORTS
 
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 2m 18s 15ms
 Avg fetch time = 71,18 ms
 Current memory = 1 708 350 400
 Max memory = 1 804 928 048
 Memory buffers = 99 999
 Reads from disk to cache = 0
 Writes from cache to disk = 1 486
 Fetches from cache = 223 855 928
 
 "FB25 not Optimized"
 26536 record(s) was(were) inserted into TMP$ITEMS
 563640 record(s) was(were) inserted into TMP$VALUES
 70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
 26536 record(s) was(were) inserted into TMP$FACTS
 2 record(s) was(were) inserted into TMP$DIMENSIONS
 1 record(s) was(were) inserted into LOG_EVENTS
 1 record(s) was(were) inserted into STAT$REPORTS
 26 record(s) was(were) inserted into TMP$ATTRIBUTES
 
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 2m 17s 453ms
 Avg fetch time = 70,89 ms
 Current memory = 1 682 077 032
 Max memory = 1 707 258 368
 Memory buffers = 99 999
 Reads from disk to cache = 3 584
 Writes from cache to disk = 1 500
 Fetches from cache = 370 518 541
 
 "FB25 Optimized"
 26536 record(s) was(were) inserted into TMP$ITEMS
 563640 record(s) was(were) inserted into TMP$VALUES
 70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
 26536 record(s) was(were) inserted into TMP$FACTS
 2 record(s) was(were) inserted into TMP$DIMENSIONS
 1 record(s) was(were) inserted into LOG_EVENTS
 1 record(s) was(were) inserted into STAT$REPORTS
 26 record(s) was(were) inserted into TMP$ATTRIBUTES
 
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 1m 9s 688ms
 Avg fetch time = 35,94 ms
 Current memory = 1 682 268 816
 Max memory = 1 707 258 368
 Memory buffers = 99 999
 Reads from disk to cache = 4
 Writes from cache to disk = 1 566
 Fetches from cache = 169 515 628
 
 |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4720 является ответом на сообщение #4717] | Thu, 28 March 2024 16:26   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| Не самый оптимальный От повтора запуска статистикак не меняется
 
 
 Оптимальныйselect sum( cast(f.FACT_VALUE as numeric(15,2)))
                             from TMP$ITEMS i
                                  join TMP$VALUES v0 on v0.ID_ITEM = i.ID  and v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                  join TMP$VALUES v7 on v7.ID_ITEM = i.ID and v7.ID_ATTRIBUTE = 7  -- код
                                  join TMP$VALUES vG on vG.ID_ITEM = i.ID and vG.ID_ATTRIBUTE = 13
                                  join TMP$FACTS f on f.ID_ITEM = i.ID
                              where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                    and v7.ATTRIBUTE_VALUE = :S7
                                    and vG.ATTRIBUTE_VALUE = :S13
                                    and f.ID_DIMENSION = :ID_PAY
План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), I INDEX (TMP$ITEMS), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))
------ Performance info ------
Prepare time = 0ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 691 251 696
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 81 104
 
 Первый пускselect sum( cast(f.FACT_VALUE as numeric(15,2)))
                             from -- TMP$ITEMS i
                                  --join TMP$VALUES v0 on v0.ID_ITEM = i.ID  and v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                  TMP$VALUES v0
                                  join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7  -- код
                                  join TMP$VALUES vG on vG.ID_ITEM = v0.ID_ITEM and vG.ID_ATTRIBUTE = 13
                                  join TMP$FACTS f on f.ID_ITEM = v0.ID_ITEM
                              where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                    and v7.ATTRIBUTE_VALUE = :S7
                                    and vG.ATTRIBUTE_VALUE = :S13
                                    and f.ID_DIMENSION = :ID_PAY
 
 Повторный пускПлан
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))
------ Performance info ------
Prepare time = 0ms
Execute time = 31ms
Avg fetch time = 31,00 ms
Current memory = 1 691 251 792
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 61 484
 
 Таблицы временные, какой там план внутри процедуры - пес его знает.План
--------------------------------------------------------------------------------
PLAN JOIN (F INDEX (TMP$FACTS_DIMENSION), V0 INDEX (TMP$VALUES), V7 INDEX (TMP$VALUES), VG INDEX (TMP$VALUES))
------ Performance info ------
Prepare time = 0ms
Execute time = 16ms
Avg fetch time = 16,00 ms
Current memory = 1 691 251 792
Max memory = 1 787 191 552
Memory buffers = 99 999
Reads from disk to cache = 0
Writes from cache to disk = 0
Fetches from cache = 61 484
 вызывается так
 
 for execute statement (PSQL) (S13:=:S13, S7:=:S7, ID_PAY:=:ID_PAY, OPER:=OPER)
 into :M17
 
 |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4728 является ответом на сообщение #4724] | Fri, 29 March 2024 12:31   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| меняем показания: 
 
 порезал код процедуры с 900 строк до 100.
 
 остался последний ES,. тормоз остался
  
 нашел четыре обращения к большим временным таблицам без ES
 
 итого:
 
 
 1. ES стали работать медленнее
 
 есть две идентичные базы 2.5 и 5.0
 в архиве - около 10 мб
 
 прислать?
 [Обновления: Fri, 29 March 2024 13:13] Известить модератора |  
	|  |  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4730 является ответом на сообщение #4716] | Fri, 29 March 2024 14:04   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| вызывается вот так (995 раз)[color=blue]ASQL[/color] = 'select 
                                    v7.ATTRIBUTE_VALUE as CODE,
                                    v8.ATTRIBUTE_VALUE as NAME,
                                    cast(v13.ATTRIBUTE_VALUE as numeric(15,2)) as PRICE,
                                    sum( cast(v14.ATTRIBUTE_VALUE as numeric(15,1))) as AMOUNT--,
                             from 
                                  TMP$VALUES v0
                                  join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7  -- код
                                  join TMP$VALUES v8 on v8.ID_ITEM = v0.ID_ITEM and v8.ID_ATTRIBUTE = 8 -- название
                                  join TMP$VALUES v10 on v10.ID_ITEM = v0.ID_ITEM and v10.ID_ATTRIBUTE = 10 -- группа услуг
                                  join TMP$VALUES v13 on v13.ID_ITEM = v0.ID_ITEM and v13.ID_ATTRIBUTE = 13 -- цена
                                  join TMP$VALUES v14 on v14.ID_ITEM = v0.ID_ITEM and v14.ID_ATTRIBUTE = 14 -- кол-во
                             where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
                                   and v7.ATTRIBUTE_VALUE = :S7
                                   and v10.ATTRIBUTE_VALUE = :S10
                             group by 1, 2, 3
                             order by 1, 2, 3';модельные параметры:
 
 OPER = 'SALE'
 S7 = '1003'
 S10 = 'Бассейн'
 
 
 
 
 
                                           DB = 'NOW';
                                           -- услуги в группировке по коду/имени/цене
                                           CNT_ASQL = CNT_ASQL + 1;
                                           for execute statement (ASQL) (S7:=:S1, S10:=:S10, OPER:=:OPER)
                                               into :S7, :S8, :S13, :S14
                                               do begin
                                                   /*
                                                   STRINGS = (select first 1 s.MON$EXPLAINED_PLAN from MON$COMPILED_STATEMENTS s
                                                   where S.MON$SQL_TEXT containing 'TMP$VALUES');
                                                   suspend;
                                                   */
                                                  end -- услуги в группировке по коду/имени/цене
                                           DE = 'NOW';
                                           STRINGS = '<!-- "'|| :S1|| '" "'|| :S2|| '"  '||datediff( millisecond, DB, DE)||' -->'; suspend;
 FB50
 
 изнутри процедуры
 
 <!-- "1003" "3083"  130.0 -->
 
 
 Select Expression
 -> Sort (record length: 2628, key length: 1044)
 -> Aggregate
 -> Refetch
 -> Sort (record length: 1152, key length: 1044)
 -> Filter
 -> Hash Join (inner)
 -> Hash Join (inner)
 -> Hash Join (inner)
 -> Hash Join (inner)
 -> Hash Join (inner)
 -> Filter
 -> Table "TMP$VALUES" as "V0" Access By ID
 -> Bitmap
 -> Index "TMP$VALUES_ATT" Range Scan (full match)
 -> Record Buffer (record length: 561)
 -> Filter
 -> Table "TMP$VALUES" as "V7" Access By ID
 -> Bitmap
 - > Index "TMP$VALUES_ATT" Range Scan (full match)
 -> Record Buffer (record length: 561)
 -> Filter
 -> Table "TMP$VALUES" as "V8" Access By ID
 -> Bitmap
 -> Index "TMP$VALUES_ATT" Range Scan (full match)
 -> Record Buffer (record length: 561)
 -> Filter
 -> Table "TMP$VALUES" as "V10" Access By ID
 -> Bitmap
 -> Index "TMP$VALUES_ATT" Range Scan (full match)
 -> Record Buffer (record length: 561)
 -> Filter
 -> Table "TMP$VALUES" as "V13" Access By ID
 -> Bitmap
 -> Index "TMP$VALUES_ATT" Range Scan (full match)
 -> Record Buffer (record length: 561)
 -> Filter
 -> Table "TMP$VALUES" as "V14" Access By ID
 -> Bitmap
 -> Index "TMP$VALUES_ATT" Range Scan (full match)
 
 отдельно, с теми же параметрами
 
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 172ms
 Avg fetch time = 172,00 ms
 Current memory = 456 180 224
 Max memory = 538 854 576
 Memory buffers = 99 999
 Reads from disk to cache = 0
 Writes from cache to disk = 0
 Fetches from cache = 255 640
 
 PLAN SORT (SORT (HASH (HASH (HASH (HASH (HASH (V0 INDEX (TMP$VALUES_ATT), V7 INDEX (TMP$VALUES_ATT)), V8 INDEX (TMP$VALUES_ATT)), V10 INDEX (TMP$VALUES_ATT)), V13 INDEX (TMP$VALUES_ATT)), V14 INDEX (TMP$VALUES_ATT))))
 
 ------------------------------------------------------------ --------------------
 ------------------------------------------------------------ --------------------
 ------------------------------------------------------------ --------------------
 
 FB25
 
 изнутри процедуры
 
 <!-- "1003" "3083"  85 -->
 
 плана, есс-но нет
 
 отдельно, с теми же параметрами
 
 План
 ------------------------------------------------------------ --------------------
 PLAN SORT (SORT (JOIN (V0 INDEX (TMP$VALUES_AV), V7 INDEX (TMP$VALUES), V8 INDEX (TMP$VALUES), V10 INDEX (TMP$VALUES), V13 INDEX (TMP$VALUES), V14 INDEX (TMP$VALUES))))
 
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 125ms
 Avg fetch time = 125,00 ms
 Current memory = 449 807 208
 Max memory = 463 328 096
 Memory buffers = 99 999
 Reads from disk to cache = 0
 Writes from cache to disk = 0
 Fetches from cache = 285 675
 
 |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4735 является ответом на сообщение #4734] | Fri, 29 March 2024 15:05   |  
			| 
				
				
					|  hvlad Сообщений: 381
 Зарегистрирован: August 2022
 | Senior Member |  |  |  
	| pastor писал(а) Fri, 29 March 2024 13:59 sim_84 писал(а) Fri, 29 March 2024 14:48А насколько большие эти GTT ?Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.я раз в два года беспокою Влада по этому поводу.
 Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
 при использовании ES в 2.5 жизнь наладилась
 
 после чесания репы, наладилась еще в 2.5 раза
 
 в 5.0 немножко вернулась взад, на исходную
 
 т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов
  ), то хочется найти пусть и обходное, но решение |  
	|  |  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4736 является ответом на сообщение #4735] | Fri, 29 March 2024 15:10   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| hvlad писал(а) Fri, 29 March 2024 15:05 pastor писал(а) Fri, 29 March 2024 13:5926 record(s) was(were) inserted into TMP$ATTRIBUTESsim_84 писал(а) Fri, 29 March 2024 14:48А насколько большие эти GTT ?Таблицы временные - оптимизатору не известны ни кардинальности, ни нормальные селективности индексов, вот и фигачит везде HASH JOIN.я раз в два года беспокою Влада по этому поводу.
 Если бы таблицы были постоянными у оптимизатора 5-ки было бы выше шансов построить оптимальный план
 при использовании ES в 2.5 жизнь наладилась
 
 после чесания репы, наладилась еще в 2.5 раза
 
 в 5.0 немножко вернулась взад, на исходную
 
 т.к. сбор отчетов через временные таблицы становится мейнстримом (кубы для нищебродов
  ), то хочется найти пусть и обходное, но решение 26536 record(s) was(were) inserted into TMP$ITEMS
 563640 record(s) was(were) inserted into TMP$VALUES
 70 record(s) was(were) inserted into TMP$ATTRIBUTE_AGREGATES
 2 record(s) was(were) inserted into TMP$DIMENSIONS
 26536 record(s) was(were) inserted into TMP$FACTS
 
 это за месяц
 около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25
 
 за год соответственно 6 млн записей
 27 мин и 11 мин соответственно
 [Обновления: Fri, 29 March 2024 15:10] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4748 является ответом на сообщение #4747] | Fri, 29 March 2024 15:50   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| select v7.ATTRIBUTE_VALUE as CODE,
 v8.ATTRIBUTE_VALUE as NAME,
 cast(v13.ATTRIBUTE_VALUE as numeric(15,2)) as PRICE,
 sum( cast(v14.ATTRIBUTE_VALUE as numeric(15,1))) as AMOUNT--,
 from
 TMP$VALUES v0
 join TMP$VALUES v7 on v7.ID_ITEM = v0.ID_ITEM and v7.ID_ATTRIBUTE = 7  -- код
 join TMP$VALUES v8 on v8.ID_ITEM = v0.ID_ITEM and v8.ID_ATTRIBUTE = 8 -- название
 join TMP$VALUES v10 on v10.ID_ITEM = v0.ID_ITEM and v10.ID_ATTRIBUTE = 10 -- группа услуг
 join TMP$VALUES v13 on v13.ID_ITEM = v0.ID_ITEM and v13.ID_ATTRIBUTE = 13 -- цена
 join TMP$VALUES v14 on v14.ID_ITEM = v0.ID_ITEM and v14.ID_ATTRIBUTE = 14 -- кол-во
 where v0.ID_ATTRIBUTE = 0 and v0.ATTRIBUTE_VALUE = :OPER
 and v7.ATTRIBUTE_VALUE = :S7
 and v10.ATTRIBUTE_VALUE = :S10
 group by 1, 2, 3
 PLAN JOIN (V0 INDEX (TMP$VALUES_AV), V7 INDEX (TMP$VALUES), V8 INDEX (TMP$VALUES), V10 INDEX (TMP$VALUES), V13 INDEX (TMP$VALUES), V14 INDEX (TMP$VALUES))
 order by 1, 2, 3
 
 дало 170->106 ms в отдельном запросе
 
 при попытке вставить в ES
 
 
Dynamic SQL Error.
SQL error code = -104.
Token unknown - line 22, column 30.
group.
<Missing arg #1 - possibly status vector overflow>.
-----------------------------------------------------------------------------------------
SQLCODE: -104
SQLSTATE: 42000
GDSCODE: 335544569 |  
	|  |  |  
	|  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4752 является ответом на сообщение #4751] | Fri, 29 March 2024 19:22   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| в эксперте прокатилло 
 а доку по планам я сегодня в первый раз читал. и вней прям буквами - "перед order"
 
 PS точно. слаб на глаза стал
 
 PPS
 
 ------ Performance info ------
 Prepare time = 0ms
 Execute time = 49s 750ms
 Avg fetch time = 49,95 ms
 Current memory = 777 161 200
 Max memory = 811 366 512
 Memory buffers = 99 999
 Reads from disk to cache = 0
 Writes from cache to disk = 6 416
 Fetches from cache = 125 050 775
 [Обновления: Fri, 29 March 2024 19:28] Известить модератора |  
	|  |  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4756 является ответом на сообщение #4755] | Sat, 30 March 2024 10:20   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| это паллиатив 
 оно и так уже на нескольких обходных решениях держится
 
 четыре предметные области, каждая со своим набором сущностей и атрибутов,
 в каждой свои критерии группировки
 
 свои  произвольные\календарные\сезонн ые\тренировочные периоды
 
 математически довольно легко формализуется
 
 решается через отчеты по временным таблицам.
 на небольших массивах - на отлично, 100% покрытие
 
 на больших - упирается в быстродействие
 лечится оно или нет? не знаю
 
 может быть есть какое-нибудь элементарное решение типа весовых коэффициентов для временных таблиц оптимизатора, которое повысит вероятность использования индекса а не хаша.
 или особенное вычисление/получение статистики индексов для временных таблиц (мы же знаем размер индекса,да?)
 или в 6-ке будут гистограммы по мере наполнения данными
 
 в исходниках оптимизатора я не ориентируюсь, вижу только внешние проявления, то вот, (стучу в бубен) взываю к Владу
 чаще всего, (Небесный Ворон отвечает) получаю дельный совет
 |  
	|  |  |  
	|  |  
	|  |  
	| 
		
			| Re: FB 5.0 Производительность, оптимизация [сообщение #4761 является ответом на сообщение #4754] | Sat, 30 March 2024 16:42   |  
			| 
				
				
					|  pastor Сообщений: 100
 Зарегистрирован: June 2022
 Географическое положение: Калуга
 | Senior Member |  |  |  
	| hvlad писал(а) Fri, 29 March 2024 23:06 pastorна 5.0 - 43 сек------ Performance info ------Это нужно сравнивать сPrepare time = 0ms
 Execute time = 49s 750ms
 
 pastor
 около 1000 проходов - 2.5 минуты на АИ50 и 1 мин на АИ25? Т.е. стало чуть лучше, чем было в 2.5 ?
 
 на 2.5 - 47 секунд
 там есть еще 4 (или уже 2? не помню) прохода по таблицам обычным запросом, без ES
 
 это первые проходы сразу после коннекта
 на втором удаляется по 600 000 записей
 
 ЗЫ процедуры сильно урезаны по сравнению с оригиналом из первого поста.
 
 [Обновления: Sat, 30 March 2024 17:01] Известить модератора |  
	|  |  |  
	|  | 
 
 
 Текущее время: Thu Oct 30 06:01:07 GMT+3 2025 
 Общее время, затраченное на создание страницы: 0.01401 секунд |