ReSQL.ru
     
powered by simpleCommunicator - 2.0.49     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / СУБД GT.M
25 сообщений из 148, страница 5 из 6
  5  все
СУБД GT.M
    #37382388
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Антон Аксёнов,

Вы уверены, что кэширование виновато? На производительность ведь много факторов влияет.
top
и
vmstat 1 10
под нагрузкой что выдают?
...
Рейтинг: 0 / 0
05.08.2011, 13:18
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37382467
Valeriu
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Valeriu
Участник
Я не знаю как насчет кэширования, но скорость убойная.
Я получаю из базы полный глобаль (одна строка больше 255 символов !!!)
на стороне клиента через TCP/IP меньше чем за 2сек
А строк примерно 10 000 тыс.
Машина простенькая (не сервер) CentOC 5.6
...
Рейтинг: 0 / 0
05.08.2011, 13:54
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37382544
Блок А.Н.
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Блок А.Н.
Участник
Ну все-таки чудес не бывает, кэширование в каком-то виде все равно тут есть.
...
Рейтинг: 0 / 0
05.08.2011, 14:41
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37382608
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Спасибо за ответы!
Я просто сравниваю кэширование с MSM, там первый проход по некоторой глобали идет 30 секунд. Второй и последующие - секунда. Потому что всё в кэше.
В GT.M пробег всегда за одно время. Не спорю, кэш там есть, только он видимо для более локальных выборок, грубо говоря ^gl=^gl+1.
Валерий, дело не в сети, с сетью у меня тоже всё круто. Я в терминалке программку запускаю, в командной строке.

Я посмотрел в интернетах - вроде никто не задавался вопросом таким, или проигнорировал. Лично для меня это не фатальная проблема - в том месте где оно явно мешает работать надо будет переписать логику, используя "новые" (по сравнению с MSM) возможности GT.M, в частности ловушки на изменение глобалей. Ну да не суть.
...
Рейтинг: 0 / 0
05.08.2011, 15:13
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37382612
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Valeriu,
Да, соглашусь с вами что скорость действительно убойная, это радует.
...
Рейтинг: 0 / 0
05.08.2011, 15:15
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37382621
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Alexey Maslov,
Выдаёт вот такое:

Код: plaintext
1.
2.
3.
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 13542  ray        20     0   12200   7580   6716  R  68 . 7    1 . 5     0 : 42 . 52  mumps
 13726  ray        20     0    2548   1208    904  R   0 . 3    0 . 2     0 : 00 . 14  top
     1  root       20     0    2812   1488   1116  S   0 . 0    0 . 3     0 : 00 . 45  init
...
Рейтинг: 0 / 0
05.08.2011, 15:19
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37382708
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Антон Аксёнов,
информации маловато для вынесения приговора :), но размер виртуальной памяти процесса mumps около 12Мб наводит на мысль, что используется дефолтный - как видно, небольшой - размер кэша.
...
Рейтинг: 0 / 0
05.08.2011, 15:59
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37384694
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Alexey,
вот vmstat под нагрузкой:
авторprocs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
1 0 39204 25836 24084 270280 0 0 7 16 57 38 1 0 98 0
1 0 39204 25828 24084 270296 0 0 0 0 284 114 94 6 0 0
1 0 39204 25828 24084 270304 0 0 0 0 305 198 94 6 0 0
1 0 39204 25828 24084 270308 0 0 0 0 282 121 94 6 0 0
1 0 39204 25828 24084 270316 0 0 0 0 303 191 94 6 0 0
1 0 39204 25828 24092 270316 0 0 0 12 289 149 95 5 0 0
1 0 39204 25828 24092 270332 0 0 0 0 307 201 97 3 0 0
1 0 39204 25828 24092 270336 0 0 0 0 281 116 94 6 0 0
1 0 39204 25828 24092 270344 0 0 0 0 304 200 95 5 0 0
1 0 39204 25828 24092 270352 0 0 0 0 285 113 95 5 0 0

ну а top
автор PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
5976 ray 20 0 12248 7944 7052 R 99.3 1.6 2:44.68 mumps
5645 ray 20 0 12032 1680 876 S 0.3 0.3 0:00.03 sshd
1 root 20 0 2812 1500 1116 S 0.0 0.3 0:00.49 init
2 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kthreadd
3 root RT 0 0 0 0 S 0.0 0.0 0:00.00 migration/0
4 root 20 0 0 0 0 S 0.0 0.0 0:00.18 ksoftirqd/0
5 root RT 0 0 0 0 S 0.0 0.0 0:00.00 watchdog/0
6 root 20 0 0 0 0 S 0.0 0.0 0:02.61 events/0
7 root 20 0 0 0 0 S 0.0 0.0 0:00.00 cpuset
8 root 20 0 0 0 0 S 0.0 0.0 0:00.00 khelper
9 root 20 0 0 0 0 S 0.0 0.0 0:00.00 async/mgr
10 root 20 0 0 0 0 S 0.0 0.0 0:00.00 pm
11 root 20 0 0 0 0 S 0.0 0.0 0:00.14 sync_supers
12 root 20 0 0 0 0 S 0.0 0.0 0:00.20 bdi-default
13 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kintegrityd/0
14 root 20 0 0 0 0 S 0.0 0.0 0:01.14 kblockd/0
15 root 20 0 0 0 0 S 0.0 0.0 0:00.00 kacpid

Меня очень смущает то что mumps грузит 100% процессора. Так же не должно быть, в диск всё должно упираться.
...
Рейтинг: 0 / 0
08.08.2011, 10:17
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37384699
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Упс, не тот тэг:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
procs -----------memory---------- ---swap-- -----io---- - system -- ----cpu----
 r b swpd free buff cache si so bi bo in cs us sy id wa
  1   0   39204   25836   24084   270280   0   0   7   16   57   38   1   0   98   0 
  1   0   39204   25828   24084   270296   0   0   0   0   284   114   94   6   0   0 
  1   0   39204   25828   24084   270304   0   0   0   0   305   198   94   6   0   0 
  1   0   39204   25828   24084   270308   0   0   0   0   282   121   94   6   0   0 
  1   0   39204   25828   24084   270316   0   0   0   0   303   191   94   6   0   0 
  1   0   39204   25828   24092   270316   0   0   0   12   289   149   95   5   0   0 
  1   0   39204   25828   24092   270332   0   0   0   0   307   201   97   3   0   0 
  1   0   39204   25828   24092   270336   0   0   0   0   281   116   94   6   0   0 
  1   0   39204   25828   24092   270344   0   0   0   0   304   200   95   5   0   0 
  1   0   39204   25828   24092   270352   0   0   0   0   285   113   95   5   0   0

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
PID USER PR NI VIRT RES SHR S %CPU %MEM  TIME + COMMAND
  5976  ray  20   0   12248   7944   7052  R  99 . 3   1 . 6   2 : 44 . 68  mumps
  5645  ray  20   0   12032   1680   876  S  0 . 3   0 . 3   0 : 00 . 03  sshd
  1  root  20   0   2812   1500   1116  S  0 . 0   0 . 3   0 : 00 . 49  init
  2  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  kthreadd
  3  root RT  0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  migration/ 0 
  4  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 18  ksoftirqd/ 0 
  5  root RT  0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  watchdog/ 0 
  6  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 02 . 61  events/ 0 
  7  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  cpuset
  8  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  khelper
  9  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  async/mgr
  10  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  pm
  11  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 14  sync_supers
  12  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 20  bdi- default 
  13  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  kintegrityd/ 0 
  14  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 01 . 14  kblockd/ 0 
  15  root  20   0   0   0   0  S  0 . 0   0 . 0   0 : 00 . 00  kacpid
...
Рейтинг: 0 / 0
08.08.2011, 10:18
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37384795
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Антон АксёновМеня очень смущает то что mumps грузит 100% процессора. Так же не должно быть, в диск всё должно упираться.Отчасти Вы сами ответили на Ваш вопрос :) упёрлось в CPU, значит, в диск не упирается, значит, с кэшированием особых проблем, по-видимому, нет. Скорее всего, несмотря на маленький дефолтный кэш в GT.M, Linux кэширует все запросы к файловой системе. Посмотрите, какой размер кэша в Linux (в том же top - параметр cached).
Однако мне попадалась статья K.S.Bhaskar'a, в которой он выявил существенный прирост производительности с увеличением GT.M-ного кэша на некоей модельной задаче. Это в общем понятно, т.к. на пересылки блоков из вторичного кэша (линуксового) в первичный (GT.M-ный) тоже уходят ресурсы CPU. Хотя такой эффект ускорения наблюдается не всегда и не везде...
...
Рейтинг: 0 / 0
08.08.2011, 11:05
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37385164
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Alexey,
У нас GLOBAL_BUFFER_COUNT стоит в 4096 (максимум), размер блока 1024, тип доступа - GB.
Вроде в документации ничего больше связанного с кэшем не нашли. А что в убунте настроить с кэшем связанное?
...
Рейтинг: 0 / 0
08.08.2011, 13:32
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37385263
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Антон,

Не считаю себя знатоком GT.M, но возможно "размер блока 1024" - не лучший выбор. Согласно К.S.Bhaskar'у (и некоторому скромному опыту :), наилучшая производительность обычно достигается при 8KB. Да и в Cache - не зря же используются 8KB блоки.

По поводу кэша в Linux'е, скорее всего, ничего делать не надо. Он и так отдаёт под кэш почти всю свободную память. Имея СУБД с собственным большим кэшем (например, Cache), наоборот, иногда хочется эту линуксовую стратегию несколько придушить.
...
Рейтинг: 0 / 0
08.08.2011, 14:16
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37385419
servit
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
servit
Участник
Антон Аксёнов ,

Посмотрите здесь , где советовал Valeriu :
increase gt.m global buffer (рабочая ссылка на mupip_set_cmmd )

Cache Performance .

Для 64-битной версии некоторые ограничения сняты :K.S. BhaskarOn 64-bit editions of GT.M, the previous per-region limits of
65,536 global buffers and 2GB shared segment size are no longer
limited by GT.M; of course, they remain limited by your actual
computing platform
PS: ещё это может пригодиться (думаю, должен быть аналог для GT.M)
...
Рейтинг: 0 / 0
08.08.2011, 15:40
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37385784
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
servit, спасибо за ответ!
Доку по команде mupip set У нас читали, по ней и настраиваем. . Что интересно по параметру GLOBAL_BUFFER_COUNT напсиано максимум 65536, однако псле всех параметров идет сводная табличка и в ней максимум уже 4096.

Размер блока поставили в 8 кб, файл пересоздали.

У нас же вообще не получается что-то большое туда воткнуть. При тех же 4096 вот такая веселуха:
Код: plaintext
1.
2.
3.
4.
5.
ray@gtm:/opt/ts/main$ gtm

GTM-main>s ^tmp( 1 )= 1 
%GTM-E-DBFILERR, Error with database file /opt/ts/main/dat/ts.dat
%GTM-I-TEXT, Error with database shmget
%SYSTEM-E-ENO22, Invalid argument

Что делать - неясно.
...
Рейтинг: 0 / 0
08.08.2011, 17:55
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386031
andrew000999
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrew000999
Гость
ошибка однозначно - не видим фай ts.dat
варианты - или файл не существует в природе
или в запускаемом модуле ( gtmroutines) указан другой файл либо не указан вообще
либо попытка использовать .dat от какойто другой версии (gtm очень чувствителен к такой беде
андрей
...
Рейтинг: 0 / 0
08.08.2011, 21:08
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386045
andrew000999
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
andrew000999
Гость
соврал не gglroutines - там программы лежат
а что-то там gbl - в общем gbl_dist= вроде бы
и еще хотелось бы узнать о количествн пользователей
gtm ОЧЕНЬ сильно работает со своими базами -не хуже msm - даже быстрее - опыт есть большой
но с фаалами ОС - тормозит со страшной силой
Андрей
...
Рейтинг: 0 / 0
08.08.2011, 21:23
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386475
rayrass
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rayrass
Гость
andrew000999ошибка однозначно - не видим фай ts.dat
варианты - или файл не существует в природе
или ...
Код: plaintext
1.
2.
3.
4.
5.
ray@gtm:/opt/ts/main/dat$ ls -al
итого  186024 
drwxr-xr-x   2  ray ray        4096   2011 - 08 - 08   15 : 55  .
drwxr-xr-x  10  ray ray        4096   2011 - 08 - 08   17 : 50  ..
-rw-rw-rw-   1  ray ray  2151760384   2011 - 08 - 08   18 : 37  ts.dat
-rw-r--r--   1  ray ray        1536   2011 - 08 - 08   15 : 29  ts.gld
Файл существует и доступ к нему есть. На сервере не работает ничего кроме собственно убунты и gt.m. Оперативки 2 гигабайта, юзер с базой работает один.
Вот что происходит, если разрисовать подробно:
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
ray@gtm:/opt/ts/main/dat$ mupip set -file ts.dat -g= 4096 
Database file ts.dat now has  4096  global buffers
ray@gtm:/opt/ts/main/dat$ gtm
GTM-main>s ^tmp( 1 )= 1 
%GTM-E-DBFILERR, Error with database file /opt/ts/main/dat/ts.dat
%GTM-I-TEXT, Error with database shmget
%SYSTEM-E-ENO22, Invalid argument
GTM-main>h
%GTM-I-MUFILRNDWNSUC, File /opt/ts/main/dat/ts.dat successfully rundown
ray@gtm:/opt/ts/main/dat$ mupip set -file ts.dat -g= 3072 
Database file ts.dat now has  3072  global buffers
ray@gtm:/opt/ts/main/dat$ gtm
GTM-main>s ^tmp( 1 )= 1 
GTM-main>h
%GTM-I-MUFILRNDWNSUC, File /opt/ts/main/dat/ts.dat successfully rundown
...
Рейтинг: 0 / 0
09.08.2011, 10:37
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386528
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Что выдаёт
Код: plaintext
$ cat /proc/sys/kernel/shmmax
?
...
Рейтинг: 0 / 0
09.08.2011, 10:56
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386557
rayrass
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
rayrass
Гость
Код: plaintext
1.
ray@gtm:/opt/ts/main/dat$ cat /proc/sys/kernel/shmmax
 33554432
...
Рейтинг: 0 / 0
09.08.2011, 11:07
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386576
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Вот и ответ на вопрос. GT.M запрашивает сегмент разделяемой памяти, размер которого равен = размер_кэша_глобалов + размер_системных_таблицы. Но уже кэш глобалов достигает потолка, заданного shmmax: 8192*4096 = 33554432 B, поэтому на самом деле вы запрашиваете больше, чем задано в shmmax. Увеличивайте shmmax (как это сделать в Ubuntu, Google вам в руки).
...
Рейтинг: 0 / 0
09.08.2011, 11:19
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386611
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Alexey Maslov,
Спасибо, подсказали)
ага, мы уже и сами поняли, ищем, пробуем.
...
Рейтинг: 0 / 0
09.08.2011, 11:31
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386715
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Разобрались, выставили. Пробовали на разных кол-вах буферов, в том числе и на 65535. Картина одна и та же: в тестовой программе которая бесконечно перебирает глобаль:
Код: plaintext
1.
2.
3.
4.
5.
  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
  9283  ray        20     0   539m  81m  81m R  96 . 8    4 . 1     0 : 37 . 45  mumps
  1446  ray        20     0   92476   28m  21m S   1 . 0    1 . 4     0 : 08 . 22  nautilus
   797  root       20     0   46648   15m  9776  S   0 . 7    0 . 7     0 : 30 . 16  Xorg
  1536  ray        20     0   40376   13m  10m S   0 . 3    0 . 7     0 : 14 . 08  wnck-applet
Загрузка по прежнему 96%-99%. А ведь в программе нет никаких расчетов.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
ray@gtm:~$ vmstat  1   10 
procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  1    0        0   1136156   104992   577556      0      0       7       7     36     91    2    0   98    0 
  1    0        0   1136148   104992   577556      0      0       0       0    296    164   100    0    0    0 
  1    0        0   1136148   104992   577556      0      0       0       0    282    120   100    0    0    0 
  1    0        0   1136148   104992   577364      0      0       0       0    297    252   98    2    0    0 
  1    0        0   1136148   105000   577532      0      0       0      16    298    318   98    2    0    0 
  1    0        0   1136148   105000   577548      0      0       0       0    298    193   99    1    0    0 
  1    0        0   1136156   105000   577548      0      0       0       4    292    139   99    1    0    0 
  1    0        0   1136156   105000   577548      0      0       0       0    295    160   100    0    0    0 
  1    0        0   1136156   105000   577356      0      0       0       0    288    212   100    0    0    0 
  1    0        0   1136032   105008   577532      0      0       0      16    302    341   97    3    0    0
...
Рейтинг: 0 / 0
09.08.2011, 12:07
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386878
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Антон, а что вы ожидали увидеть? По-видимому, ваш глобал полностью влезает в кэш, это объясняет отсутствие дискового i/o. Ваш процесс - единственная активная задача, вот и забирает весь CPU, который у вас 1-ядерный. Что-то (немного) теряется на передаче данных по сети (вы ведь, наверное, что-то куда-то выводите).
Запустите что-нибудь еще, и они CPU поделят. Или вставьте периодические искусственные задержки (hang 1), только неясно, зачем.
На Cache for Linux, если я запущу обход небольшого глобала, тоже заберу 100% одного из ядер.
...
Рейтинг: 0 / 0
09.08.2011, 12:53
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37386911
Alexey Maslov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Alexey Maslov
Участник
Про ядра погорячился, top не позволяет судить об их количестве и показывает, на самом деле, загрузку ядра (ядер). Если процесс многопоточный, top может показать и 200%.
...
Рейтинг: 0 / 0
09.08.2011, 13:01
| Ответить | Цитировать | Написать  
СУБД GT.M
    #37387018
Антон Аксёнов
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Антон Аксёнов
Гость
Да понимаете, дело не в том что мне жалко процессорного времени, отнюдь.
Мне непонятно почему обход глобала занимает постоянно 3 секунды, на каждой итерации. В MSM же тот же глобал (те же данные) обход после того как всё ляжет в кэш происходит практически мгновенно. Я просто понять не могу, где сам кэш-то? Я как-то ожидал что gt.m будет если не заруливать то уж так же по времени работать.
...
Рейтинг: 0 / 0
09.08.2011, 13:31
| Ответить | Цитировать | Написать  
25 сообщений из 148, страница 5 из 6
  5  все
Форумы / Caché, Ensemble, DeepSee, MiniM, IRIS, GT.M [игнор отключен] [закрыт для гостей] / СУБД GT.M
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=39&msg=37385419&tid=1557025]:
 0ms
get settings:
 10ms
get forum list:
 13ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 144ms
get topic data:
 12ms
get forum data:
 3ms
get page messages:
 70ms
get tp. blocked users:
 2ms
others: 17ms
total:  277ms
созд. / загр.: 277ms
x
x
Закрыть


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