komradВикторррПо совету cherrex_Den заглянул в erorlog ASE, увидел 3 типа ошибок, которых раньше не было.
1. Встречается очень часто
kernel ksctsetlocale: connectivity library error. Operation: Msg. 33818168, Severity 6, cs_locale: cslib user api layer: common library error: Failed to map a local name to an object id!.
kernel ksctsetlocale: connectivity library error. Operation: cs_locale(CS_SET CS_SYB_SORTORDER rusnocs_cp866).




2001 59 52 0 rusnocs_cp866 Russian case-insensitive dictionary sort order for use in Russia. Uses the IBM codepage cp866 character set and is case-insensitive. 0C009F000000010101000102020001030300010404000105050001060600010707000108080001090900010A0A00010B0B00010C0C00010D0D00010E0E00010F0F0001101000011111000112120001131300011414000115150001161600011717000118180001191900011A1A00011B1B00011C1C00011D1D00011E1E00011F1F0001202000015F2600013F2E0001283B0001253600012A3C00012B390001FC2D0001222F0001293000015B3700015C3D00013C2300013B2200012C290001602800012E7A0001317B0001327C0001337D0001347E0001357F00013680000137810001388200013983000161250001212400013A3E00013D3F00013E4000017C2700012F350001248400026285000263860002648700026588000266890002678A0002688B0002698C00026A8D00026B8E00026C8F00026D9000026E9100026F92000270930002719400027295000273960002749700027598000276990002779A0002789B0002799C00027A9D0002A03100015D380001263200017B2B00017E2100012D2A00015E8400016285000163860001648700016588000166890001678A0001688B0001698C00016A8D00016B8E00016C8F00016D9000016E9100016F92000170930001719400017295000173960001749700017598000176990001779A0001789B0001799C00017A9D0001A03300017D4100017F340001402C000127420001B09E0002A19F0002A2A00002A3A10002A4A20002A5A30002F3A60002A7A70002A8A80002F5AA0002AAAB0002ABAC0002ACAD0002ADAE0002AEAF0002AFB00002E0B10002E1B20002E2B30002E3B40002F7B60002E5B70002E6B80002E7B90002E8BA0002E9BB0002EABC0002EBBD0002ECBE0002EDBF0002EEC00002EFC10002009E0001A19F0001A2A00001A3A10001A4A20001A5A30001F3A60001A7A70001A8A80001F5AA0001AAAB0001ABAC0001ACAD0001ADAE0001AEAF0001AFB00001E0430001B1440001B2450001B3460001B4470001B5480001B6490001B74A0001B84B0001B94C0001BA4D0001BB4E0001BC4F0001BD500001BE510001BF520001C0530001C1540001C2550001C3560001C4570001C5580001C6590001C75A0001C85B0001C95C0001CA5D0001CB5E0001CC5F0001CD600001CE610001CF620001D0630001D1640001D2650001D3660001D4670001D5680001D6690001D76A0001D86B0001D96C0001DA6D0001DB6E0001DC6F0001DD700001DE710001DF720001F8B10001E1B20001E2B30001E3B40001F7B60001E5B70001E6B80001E7B90001E8BA0001E9BB0001EABC0001EBBD0001ECBE0001EDBF0001EEC00001EFC1000100A50002A6A50001A6A40002F1A40001F1A90002A9A90001A9B50002E4B50001E4730001F9740001FA750001FB760001FD3A000123770001FE780001FF79000130FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000 rusnocs.srt

Сейчас наблюдал процесс падения памяти "в прямом эфире". Т.к. утром перезагрузил сервер, то служба весь день была 4,1 Гб. Примерно без десяти шесть, служба РЕЗКО упала с 4,1 Гб до 56 Мб (примерно, т.к. случайно увидел все это), коннекты НЕ отвалились, начисления, которые работали в этот момент продолжали работать, т.е. визуально ничего не произошло, все как работало, так и продолжило работать. Сразу же после этого, служба начала расти и через 20 мин. стала 3,7 Гб. В момент падения посмотрел
select cachename,sum(cachedkb) from master..monCachedObject
group by cachename

default data cache 3145286
tempdb_cache 28496

Параметры total physical memory и total logical memory - 4 Гб, т.е. сайбейс и не заметил, что с ним произошло!?!?

Посмотрел логи ASE и винды - чисто!!! Своп, как я полагаю, отключен. Чудо. :(

komradВикторрр
2001 59 52 0 rusnocs_cp866 Russian case-insensitive dictionary sort order for use in Russia. Uses the IBM codepage cp866 character set and is case-insensitive. 0C009F000000010101000102020001030300010404000105050001060600010707000108080001090900010A0A00010B0B00010C0C00010D0D00010E0E00010F0F0001101000011111000112120001131300011414000115150001161600011717000118180001191900011A1A00011B1B00011C1C00011D1D00011E1E00011F1F0001202000015F2600013F2E0001283B0001253600012A3C00012B390001FC2D0001222F0001293000015B3700015C3D00013C2300013B2200012C290001602800012E7A0001317B0001327C0001337D0001347E0001357F00013680000137810001388200013983000161250001212400013A3E00013D3F00013E4000017C2700012F350001248400026285000263860002648700026588000266890002678A0002688B0002698C00026A8D00026B8E00026C8F00026D9000026E9100026F92000270930002719400027295000273960002749700027598000276990002779A0002789B0002799C00027A9D0002A03100015D380001263200017B2B00017E2100012D2A00015E8400016285000163860001648700016588000166890001678A0001688B0001698C00016A8D00016B8E00016C8F00016D9000016E9100016F92000170930001719400017295000173960001749700017598000176990001779A0001789B0001799C00017A9D0001A03300017D4100017F340001402C000127420001B09E0002A19F0002A2A00002A3A10002A4A20002A5A30002F3A60002A7A70002A8A80002F5AA0002AAAB0002ABAC0002ACAD0002ADAE0002AEAF0002AFB00002E0B10002E1B20002E2B30002E3B40002F7B60002E5B70002E6B80002E7B90002E8BA0002E9BB0002EABC0002EBBD0002ECBE0002EDBF0002EEC00002EFC10002009E0001A19F0001A2A00001A3A10001A4A20001A5A30001F3A60001A7A70001A8A80001F5AA0001AAAB0001ABAC0001ACAD0001ADAE0001AEAF0001AFB00001E0430001B1440001B2450001B3460001B4470001B5480001B6490001B74A0001B84B0001B94C0001BA4D0001BB4E0001BC4F0001BD500001BE510001BF520001C0530001C1540001C2550001C3560001C4570001C5580001C6590001C75A0001C85B0001C95C0001CA5D0001CB5E0001CC5F0001CD600001CE610001CF620001D0630001D1640001D2650001D3660001D4670001D5680001D6690001D76A0001D86B0001D96C0001DA6D0001DB6E0001DC6F0001DD700001DE710001DF720001F8B10001E1B20001E2B30001E3B40001F7B60001E5B70001E6B80001E7B90001E8BA0001E9BB0001EABC0001EBBD0001ECBE0001EDBF0001EEC00001EFC1000100A50002A6A50001A6A40002F1A40001F1A90002A9A90001A9B50002E4B50001E4730001F9740001FA750001FB760001FD3A000123770001FE780001FF79000130FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000FF0000000000000000000000 rusnocs.srt

а можно это в виде таблички с полями ?

Файликов с таким именем много, привел 2, для cp866 и cp1251.

А кто знает, что означает адрес 23662592 в параметре shared memory starting address = 23662592? Может это адрес для х86, а для х64 он должен быть иным и отсюда все эти чудеса?

cherrex_DenВикторрр,
Да что вы "паритесь"? Если при снижении память у вас сервер не упал, коннекты не отвалились и кэши сохранились, то скорее всего это глюк винды(отображение в таск менаджере)!

Раньше я смотрел на размер службы в таск менеджере и она действительно, то уменьшается, то увеличивается в размере, но теперь смотрю еще и monCachedObject и вижу, что в определенные моменты кеш УМЕНЬШАЕТСЯ, хотя как я понял из общения с форумчанами, кеш не может уменьшиться ни при каких обстоятельствах, но он уменьшается!!! :( Утром перезагрузил сервер, служба забрала 4 Гб, посмотрел в monCachedObject кеш 300 мб, запустил отчет, кеш дорос до 900 мб, через минуту после выполнения (может это и не связано с отчетом) кеш уменьшился до 700 мб и опять продолжил расти. Сейчас 3,1 Гб, как и должен быть, но вчера наблюдал (по мониторинговым таблицам), что он с 3,1 Гб, уменьшался до 2,6, хотя служба была 3,9 Гб, потом опять вырос.

cherrex_DenВикторрр,
Тормоза прошли после убийства пула 16К в дефолтном кэше???


Не готов пока ответить, т.к. кручу много чего, но результата устраивающего меня самого, пока не добился. Когда кеш разбивается на пулы, например кеш 3 Гб, пул 2К - 2Гб, пул 16К - 1Гб, но приложение построено так, что мало использует вывод большими блоками, то что, этот гигабайт будет просто пропадать за зря и не использоваться?

Вот, нарыл на буржуйских сайтах о памяти:

This is a post from Tony Imbeierski (sorry, I'm sure I spelled that wrong)
from a while ago ... bottom line is to set the shared starting memory
address and set the /3GB option in the boot.ini file. You should then be
able to get close to 2.5 gig total memory.


The shared memory starting address is not a size of anything, it is the
address
in our virtual address space where ASE starts mapping its shared memory.

Virtual address spaces on NT are always 4Gb in size (regardless of how much
physical memory the machine has). Addresses from 0 to 7FFFFFFF (hex) are
normally available to the application (in this case, ASE). Addresses from
80000000 to FFFFFFFF are reserved for the system. If you have enterprise NT
with
the /3GB option, then the application is given from 0-BFFFFFFF and the
system
gets C0000000-FFFFFFFF.

The way the application memory is split up is as follows. Starting at the
bottom
and working upwards, the first few pages from 0-FFF hex are reserved and are
known as the guard pages. The main application code (in this case
sqlsrvr.exe)
loads at 400000 (hex). Above and below this, shared libraries such as libct,
libsrv (connectivity) get loaded. Then somewhere on top of this lot you get
application private data areas. Once all this is loaded, we have a chunk of
address space free to create our shared memory.

By default we request shared memory starting at 20000000 (hex). This equals
536870912 and is probably the '500mb' you are referring to, but remember
this
isn't a size, it's merely the starting address. Theoretically then the
maximum
size of shared memory is the amount that can fit between 20000000 and
7FFFFFFF
(on a normal system) or 20000000 and BFFFFFFF on an enterprise NT system.
Almost
but not quite, as NT stuffs some system dll's (kernel32.dll for example)
right
at the top which restricts us slightly. Ignoring this for the moment, this
allows up to 5FFFFFFF bytes of shared memory or 9FFFFFFF on an enterprise
system. Convert these numbers to decimal and you get 1,610,612,735 or on the
enterprise system 2,684,354,559. Or about 1.5Gb (normal) / 2.5Gb
(Enterprise).
(remember actually slightly less because of those system dlls taking up
space at
the top).

Now the top end of the address space is a hard limit fixed by the OS. But we
can
squeeze in more by lowering the place we start shared memory. This is the
purpose of the 'shared memory starting address'. The number you were given
(23662592) equates to 1691000 hex. This means the amount of shared memory we
can
squeeze in becomes 7FFFFFFF-1691000 = 7E96EFFF hex or 2123821055 decimal or
1.9
Gb (except not quite that big because we can't go all the way up to 7fffffff
remember). Enterprise systems again get a gig more.

So where did we come up with the number 23662592? To be honest, probably
trial
and error. The lower you make the shared memory starting address, the more
shared memory you can have, until you make it so low that it clashes with
memory
already allocated for some other purpose. We actually cope with that
situation
and increase the value internally until it reaches a clear space. However
you
are then in a position where the server has absolutely no free space in its
virtual address range at all, which may lead to a memory allocation failure
some
time down the line. You also have the problem that other applications such
as
monitor server that want to map the shared memory may not be able to because
they themselves may not have that low area free. The 23662592 figure is
probably
one that has been recommended many times by tech support and works.

As for the default, this was originally chosen to be a round number (in hex
anyway) that is way up in the address range that will never cause conflict
with
other areas already in use. Remember this default was set when the server
was
first ported to NT in what, 94? Nobody dreamed of PC systems with 4Gb
physical
ram back then. It's probably about time the default was reviewed to a lower
value, I might make this suggestion internally.

I just thought of a good analogy for your managers. Imagine the total
application space is like Route 66. By default we start shared memory in
Chicago
and end it in LA. Lowering the shared memory is like starting Route 66 in
New
York - it gets longer. But move the start too far east and you end up trying
to
build a road in the sea 8*)

HTH,
tonyi

И вот еще немного:

I've seen a few postings asking how to get the largest memory allocation on
a Windows 32-bit platform on ASE 12.5.x. Here is what I've pieced together
over the last couple of years. In early testing the same configuration
applies to ASE 15.0 too.

Note that this isn't the last word on how to configure Sybase for large
memory in Windows (I'm sure there must be tricks to squeeze even more memory
out of the system) but these tips work well for me.
-----

The Microsoft Windows operating system, running on a 32 bit platform has
memory address limits for the maximum size a process may be. While, given
sufficient memory, Windows will allow multiple instances of Sybase with
large memory allocations, there is a maximum size each individual Sybase
process may be.

In order to maximise the size a process may be in Windows the operating
system should be booted with the /3GB option(specified in C:\boot.ini) which
limits the operating system kernel to using 1GB of memory, allowing a
(theoretical) maximum individual process size of 3GB.

If more than 4GB of memory is to be used the /PAE setting must also be added
in boot.ini. This will allow multiple 3GB processes (with each process not
more than 3GB). Note that Windows Server 2003 Enterprise edition (or
greater) is required to use more than 4GB of memory.

Given these boot options, on a server with at least 4GB memory, the
following maximum memory sizes may be set for Sybase:

Windows 2000 Professional/Windows XP: 761810 (2k pages) = 1,487.9MB
Windows Server 2003: 1522000 (2k pages) = 2,972.7MB

If allocating more than 2GB of memory the Sybase configuration option
"shared memory starting address" must be set to 23662592. Also, you must set
the Windows Virtual Memory setting ("paging size") to at least 4GB.

Note that if the Sybase 'max memory' option is set higher than the above
settings, if memory is allocated over these settings Sybase will hang, and
then will fail to start.

Should you require large memory allocation (eg. for a large data cache) it
is recommended to use a 64-bit Linux on a x64-64 processor. Sybase ASE is
not available at present on a 64-bit Windows platform although I understand
that Sybase have plans to release Sybase 15.0 for Windows x86-64 during
Quarter 3, 2006.

Useful links:

Microsoft: A description of the 4 GB RAM Tuning feature and the Physical
Address Extension switch
Sybase: Addressable Memory Limits

Also, you must set the Windows Virtual Memory setting ("paging size") to at least 4GB.

Где это нужно устнановить Windows Virtual Memory setting ("paging size") to at least 4GB???

cherrex_DenВикторрр,

ВикторррРаньше я смотрел на размер службы в таск менеджере и она действительно, то уменьшается, то увеличивается в размере, но теперь смотрю еще и monCachedObject и вижу, что в определенные моменты кеш УМЕНЬШАЕТСЯ, хотя как я понял из общения с форумчанами, кеш не может уменьшиться ни при каких обстоятельствах, но он уменьшается!!! :( Утром перезагрузил сервер, служба забрала 4 Гб, посмотрел в monCachedObject кеш 300 мб, запустил отчет, кеш дорос до 900 мб, через минуту после выполнения (может это и не связано с отчетом) кеш уменьшился до 700 мб и опять продолжил расти. Сейчас 3,1 Гб, как и должен быть, но вчера наблюдал (по мониторинговым таблицам), что он с 3,1 Гб, уменьшался до 2,6, хотя служба была 3,9 Гб, потом опять вырос.

Какой кэш? Дефолтный?

Уменьшаются, на самом деле, оба кеша, и дефолтный и темп ДБ. Почему уменьшается темп БД, вы объяснили, это понятно. Но вот с дефолтным кешем, п. 1-3 явно системные процедуры, которые не делаются ежедневно и уж тем более несколько раз в день в рабочее и не рабочее время. На счет п.4 , я так понимаю, что все временные таблицы (с #) создаются в темп ДБ и там же потом и дропаются. Таблицы из базы могут удаляться лишь при обновлениях версии 5НТ либо еще каких-то системных процедурах, но опять не среди бела дня.

cherrex_DenПочему размер данных в кэше может уменьшиться(очистка кэша):

1. Вы убиваете кэш, следовательно все обьекты в этом кэше не в памяти.
2. Вы убиваете пул, следовательно все обьекты в этом пуле не в памяти.
3. Вы перебиндете обьекты на другой кэш, следовательно все обьекты должны считаться занова в новый кэш.
4. Вы убиваете обьект следовательно и страницы этого обьекта удаляются из кэша.

Что происходит в tempdb, вернее в его кэше. Вы запускаете отчет(процедуру), зачистую эта процедура создает временные таблицы в tempdb, и ложит туда какие-нибудь данные. Естественно когда вы посмотрите на monCachedObject, то кэш tempdb, будет большой. Потом процедура при завершении, чистит за собой все временные таблицы. И monCachedObject покажет вам что кэш совсем пустой. Но это только с кэшем tempdb!!! Размер других именнованных кэшей, не должен падать. Или в пративном случае происходит что-то из перечисленного выше. В пративном случае, ASE должен упасть, или это БАГ.

Не падает, лог пустой, дефолтный кеш изменяется постоянно в приделах 2,8-3,1 Гб. От стратегии это не может зависеть? У меня выбрана strict LRU replacement и на дефолтном и на темп ДБ кеше, может нужно выбрать другую стратегию? Какую для дефолтного и какую для темп ДБ кеша?

cherrex_DenЯ вам 10-тый раз повторяю, не тюньте сервер, а смотрите планы, и сами запросы. Чего не хватает опрелеленным запросам. А потом разбирайтесь с общими настройками сервера, если конечно они виноваты. Вы пытаетесь ткнуть на угад пальцем в небо, и попасть в солнце.

Если с настройками сервера я, хотя бы отчасти, понимаю ГДЕ и ЧТО нужно крутить и к чему это приводит, то с планами запросов, не знаю даже "где", не говоря уже о том "что". Где увидеть план запроса и на что там нужно смотреть?

ВикторррНе готов пока ответить, т.к. кручу много чего, но результата устраивающего меня самого, пока не добился. Когда кеш разбивается на пулы, например кеш 3 Гб, пул 2К - 2Гб, пул 16К - 1Гб, но приложение построено так, что мало использует вывод большими блоками, то что, этот гигабайт будет просто пропадать за зря и не использоваться?

cherrex_DenПо логике ДА! Но я не верю что он у вас так ни где и не используется. И что значит: но приложение построено так, что мало использует вывод большими блоками

Я сисмоном собираю статистику и по ней вижу, что 99,99% ввода/вывода идет через пул 2К, для эксперимента сделал 100 Мб 16К пул, но т.к. судя по сисмону он не используется, уменьшил до 10Мб, а теперь убрал его вообще. На темп ДБ другая ситуация, сделал именованный кеш 300 Мб, пулы 200 Мб - 2К, 100Мб -16К, сисмон показывает, то 60% через 16К пул, то 0%. Но т.к. 300 мб ему много, сделал 100 Мб кеш, пул 40 Мб - 2К, 60Мб -16К. Пока так. А как правильно определить размер 16К пула?

cherrex_DenХотя в голову пришло следующее:

У вас же кэш один, дефолтный, а значит к нему прибиндена и база master.
А в базе master, есть очень динамические системные таблицы(syslock, sysobject итд).
Так вот, вполне возможно, что в этом и есть причина вашего снижения в дефолтном кэше.

MasterZiv, moris или komrad, ответьте на вопрос!!!

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

Если таблица с построчной блокировкой, то ее страницы не исчезают физически при делете, а исчезнут только при reorg. При APL, страницы умирают, и скорее всего и из кэша они удаляются. А в 12.5 все ситемные таблицы APL!

Викторрр, попробуйте разнесть пользовательские и системные базы по разным кэшам, и посмотрите будет ли падать пользовательский кэш?

Т.е., я уменьшаю размер дефолтного кеша до 300 мб, создаю новый именованный кеш на 2,8 Гб, отвязываю пользовательские базы от дефолтного кеша, привязываю к новому кешу и смотрю на результат. Или в дефолтном кеше оставить пользовательские базы, а под master, model, sybsystempdb и sybsystempprocs сделать новый кеш?

По поводу уменьшения размера службы в памяти, тех поддержка ответила, что это нормальное поведение службы под виндой. НО это НОРМАЛЬНОЕ поведение появилось сразу после перехода на х64 винду, на х86 токого не было. По поводу кешей пока нет информации.

Настроил сбор статистики раз в час, Sysmon, размер службы и кеша. Вот статистика по памяти с пятницы по сейчас.

Вложение не прикрепилось. :(

cherrex_DenВикторрр,

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

Второе:
Как у вас делается дамп транзакций, делается ли он вообще? На ваших базах стоит ли галочка truncate log on chekpoint? Если нет, какаое расписание дампов у вас.

Просто, еще ваш лог(syslogs), может забивать весь кэш вытисняя нужные страницы, а потом при дампе лога, резко очищаться! Если дамп делается ночью, то вот вам и обьяснение почему ночью кэш становиться маленьким. Вернее пустым.

Дамп лога снимается и поднимается на резервный сервер каждые 20 мин с 7:40 до 23:45. В 00:05 запускается снятие полного дампа. Галка, соответственно, снята. Если база мастер всего 200 мб, то разве она сможет забить весь кеш?

cherrex_DenВикторрр,

ВикторррЕсли база мастер всего 200 мб, то разве она сможет забить весь кеш?

У вас все базы(кроме tempdb) к одному кэшу прибиты!

Я с основного сервера все базы убрал, кроме двух основных (для разных продуктов), лишних баз там нет.

cherrex_DenЯ вам выдал все возможные варианты почему кэш опусташается.
Так что пробуйте,экспериментируйте, разнесите кэши не только по базам, но я бы попробывал и по лагам и данным отдельные кэши сделать. И осмотреть в каких роисходит очистка!

В выходные крутил сервер. Добавил именованный кеш на базу Оренбург, теперь дефолтный кеш 150 Мб (2к - 80Мб, 16к - 70Мб), Оренбург 3,1 Гб (2к - 2,8Гб, 16к - 300Мб), ТемпДБ 110 Мб (2к - 50Мб, 16к - 60Мб). По мониторным таблицам четко видно, что уменьшается кеш, именно базы Оренбург, примерно на 300 Мб. А как разделить кеши данных и логов? В централе же только два варианта: 1) данные и лог 2) только лог.
Как увидеть, используется ли и если да, то на сколько 16 к пук кеша? сисмон очень часто рекомендует удалить 16к пул...

Настроил еще паралеризацию, вот так:
[Parallel Query]
number of worker processes = 8
memory per worker process = 1296
max parallel degree = 2
max scan parallel degree = 2

arpaВикторрр,

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

Я уже писал, что перейти на 15 мы не можем, поэтому ограничены 32 битным Sybase 12.5.1. Проблема с производительностью решена, топорно, покупкой СХД на Flash дисках. Это сняло проблему производительности как таковую в принципе. Но общение в форуме очень помогло привести базу в порядок. Спасибо Вам всем. Вообще, флеш диски - это вещь, не гудят, не грются, скорость!!! Вобщем, рекомендую. Только дорого. :( Помимо СХД, добавил вторую tempdb (правда сомневаюсь, не стало ли с ней хуже) и оставил windows 2003 X64 - это позволило выделить Sybase 4 Гб оперативки. Процесс ведет себя как и раньше, при загрузке - 4 Гб, потом обычно ночью (при не использовании наверное), процесс уменьшается в размере, но потом растет обратно до 4х гб. Файл подкачки в винде отключил. Именованные кеши убрал, пользы от их наличия увидеть не удалось. Сегмент system выделил в отдельный файл. CheckDB и апдейт статистики делаю раз в неделю в выходные. Может еще что-то нужно делать, для профилактики? В целом все нормально работает, за исключением одного НО. Периодически, несколько раз в неделю в логах появляются сообщения "SQL Server system exception (0xc0000005) generated by a storage access violation", об этом писал в форуме весной. Причину этих ошибок пока выяснить так и не удалось. Редкие сообщения в интернете ответа на вопрос не дали, сейчас тестирую параметр cpu grace time, увеличил его до 1500, но не похоже что он. Летом переставял сервер (ОС и СУБД), данные переехали на СХД, т.е. все настроено заново, но сообщения в логе, всеравно появляются. Из рабочих гипотез: 1. проблема с оперативной памятью (раньше памяти было 4 гб, зимой увеличил до 16 гб - весной появились ошибки), но нет не похоже что память. 2. Битый диск на котором хранятся данные - тоже нет (база и темпбд переехали на СХД, но ошибки всеравно есть) 3. На 12.5.1 глючит множественная темпдб - пробовал убирать вторую базу, оставив лишь первую, но ошибки есть, не знаю можно ли из группы 'default' убрать первую базу оставив лишь вторую? Если только так еще попробовать? В пользу версии, что проблема с темпдб, говорит такой факт, был один глюк с работающим отчетом, с 4-12 раза его запуск стал выдавать в лог портянки ошибок и отчет вываливался. Обрадовался, что появилась тестовая среда, на которой можно отловить ошибку. Нашел то место, которое вызывает сбой - селект с MAX по полю из временной таблицы, причем остальные 3-11 запусков по тем же данным отрабатывают нормально, и лишь иногда сбоит. Убрав MAX отчет начинает стабильно работать. Возврат max опять его ломает. Но после перезагрузки сервера все опять заработало и тестовая среда пропала. Чтобы еще посмотреть про tempDB? 4. Работа 32 битного сайбеса под 64 битной виндой - эта гипотеза также актуальна, если к моменту следующей переустановки ОС проблема останется, переставлю винду на 32 битную, проверю. В логах винды все чисто.

Sybase: DBMS Version Adaptive Server Enterprise/12.5.1/EBF 11665 ESD#2/P/NT (IX86)/OS 4.0/ase1251/1838/32-bit/OPT/Fri Feb 20 04:11:31 2004


Ошибки такого вида (Message_test - тестовый отчет):


02:00000:00069:2010/11/23 09:44:47.68 kernel SQL Server system exception (0xc0000005) generated by a storage access violation.02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x004B779B (Symbol not found)(0x02260002, 0x00000001, 0x00000001, 0x004B0002)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x004B779B (Symbol not found)(0x00000003, 0x10020000, 0x00000000, 0x022970E0)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x004B76E0 (Symbol not found)(0x787799C5, 0x00000001, 0x7877BA64, 0x7877B0E4)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x004B7675 (Symbol not found)(0x1192F000, 0x00000110, 0x7877BA64, 0x7877B0E4)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x004B3ED5 (Symbol not found)(0x787799C4, 0x00000001, 0x1192F4FC, 0x07FFB98C)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x00D93704 XMLFormatter::specialFormat+ 0xe614 (0x787799C4, 0x00000001, 0x00000000, 0x09D88028)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x0091278C (Symbol not found)(0x7877B0C4, 0x15547628, 0x7877FEAE, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x008F9773 (Symbol not found)(0x08003455, 0x7877F6A0, 0x7877F6A0, 0x7877F6A0)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x009267F0 (Symbol not found)(0x0044B2D5, 0x08003455, 0x7877FEAE, 0x07FFB98C)
02:00000:00069:2010/11/23 09:44:47.68 kernel [Handler pc: 0x008F83A0 (Symbol not found) installed by the following function:-]
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x008F7F31 (Symbol not found)(0x07FFB900, 0x00000000, 0x00000000, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x004533A9 (Symbol not found)(0x000000BE, 0x00000000, 0x00000000, 0x09D88028)
02:00000:00069:2010/11/23 09:44:47.68 kernel [Handler pc: 0x00472864 (Symbol not found) installed by the following function:-]
02:00000:00069:2010/11/23 09:44:47.68 kernel [Handler pc: 0x006D8E30 (Symbol not found) installed by the following function:-]
02:00000:00069:2010/11/23 09:44:47.68 kernel [Handler pc: 0x006D8E30 (Symbol not found) installed by the following function:-]
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x0041AF0F (Symbol not found)(0x09D88028, 0x00000000, 0x00000000, 0x09D88028)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x00B34897 AseHTTPURLInputStream::readBytes+ 0x6c5b1 (0x00B34813, 0x09D88028, 0x00000000, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.68 kernel pc: 0x7D4DFE37 kernel32.dll (0x00000000, 0x00000000, 0x00000000, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.68 kernel end of stack trace, spid 69, kpid 921108658, suid 81
02:00000:00069:2010/11/23 09:44:47.68 kernel ************************************
02:00000:00069:2010/11/23 09:44:47.68 kernel SQL causing error : InDateTime = case when ac.TypeAcc = 1
then (select min(rd2.InDateTime)
from tResDate rd2 (index XPKtResDate)
inner join tPropertyUsr pu2 (
02:00000:00069:2010/11/23 09:44:47.68 kernel ************************************
02:00000:00069:2010/11/23 09:44:47.68 server SQL Text: InDateTime = case when ac.TypeAcc = 1
then (select min(rd2.InDateTime)
from tResDate rd2 (index XPKtResDate)
inner join tPropertyUsr pu2 (index XPKtPropertyUsr)
on pu2.PropertyUsrID = rd2.PropertyUsrID
and pu2.Brief = 'НомСообФНС'
and rd2.ResDateID = rd.ResDateID)
else (select max(rd2.InDateTime)
from tResDate rd2 (index XPKtResDate)
inner join tPropertyUsr pu2 (index XPKtPropertyUsr)
on pu2.PropertyUsr
02:00000:00069:2010/11/23 09:44:47.70 kernel curdb = 5 tempdb = 2 pstat = 0x50000
02:00000:00069:2010/11/23 09:44:47.70 kernel lasterror = 0 preverror = 0 transtate = 1
02:00000:00069:2010/11/23 09:44:47.70 kernel curcmd = 0 program = R[Message_test.
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00BB1A3D AseHTTPURLInputStream::readBytes+ 0xe9757 (0x78777C1C, 0x7D4D89E0, 0x7D4D8F38, 0xFFFFFFFF)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00BB1A3D AseHTTPURLInputStream::readBytes+ 0xe9757 (0x78777C1C, 0x787779D4, 0x0000270F, 0x00000002)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00B89C5A AseHTTPURLInputStream::readBytes+ 0xc1974 (0x36E700B2, 0x00000002, 0x0000270F, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00B898E4 AseHTTPURLInputStream::readBytes+ 0xc15fe (0x36E700B2, 0x00000001, 0x00000000, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00B3F33B AseHTTPURLInputStream::readBytes+ 0x77055 (0x36E700B2, 0xFFFFFFFF, 0xC0000005, 0x07FFB98C)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x0040737E (Symbol not found)(0xC0000005, 0x77BC6CD5, 0x787781A0, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00B33D79 AseHTTPURLInputStream::readBytes+ 0x6ba93 (0x09D88028, 0x00000000, 0x00000000, 0x09D88028)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x00B34917 AseHTTPURLInputStream::readBytes+ 0x6c631 (0x00B34813, 0x09D88028, 0x00000000, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.70 kernel pc: 0x7D4DFE37 kernel32.dll (0x00000000, 0x00000000, 0x00000000, 0x00000000)
02:00000:00069:2010/11/23 09:44:47.70 kernel end of stack trace, spid 69, kpid 921108658, suid 81