Sybase NNTP forums - End Of Life (EOL)

The NNTP forums from Sybase - forums.sybase.com - are now closed.

All new questions should be directed to the appropriate forum at the SAP Community Network (SCN).

Individual products have links to the respective forums on SCN, or you can go to SCN and search for your product in the search box (upper right corner) to find your specific developer center.

[ASE] 2k -> 16k migration

5 posts in General Discussion Last posting was on 2012-10-26 10:21:35.0Z
mnj Posted on 2012-10-11 11:14:33.0Z
From: mnj <marcin.najs@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:15.0) Gecko/20120907 Thunderbird/15.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: [ASE] 2k -> 16k migration
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <5076aa19$1@forums-1-dub>
Date: 11 Oct 2012 04:14:33 -0700
X-Trace: forums-1-dub 1349954073 172.20.134.152 (11 Oct 2012 04:14:33 -0700)
X-Original-Trace: 11 Oct 2012 04:14:33 -0700, vip152.sybase.com
Lines: 19
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31422
Article PK: 74311

Hi.
Can someone explain if ASE 2k->16k migration
can improve overall (I/O) database performance (and how):

1. oltp environment (with small number
of DSS/Report queries)
2. Page 2k
3. Data cache (2k & 16k pools (16k-20% of cache size))
4. SMP environment (4-8 ASE engines)
5. Large number of concurent connections
6. Row-level locking scheme

I have never considered migrating to 16k and make
any tests. Maybe there are some general advantages...
Any suggestions?

Best Regards
--
marcin


Cory Sane [TeamSybase] Posted on 2012-10-12 04:00:26.0Z
From: "Cory Sane [TeamSybase]" <cory!=sane>
Newsgroups: sybase.public.ase.general
References: <5076aa19$1@forums-1-dub>
In-Reply-To: <5076aa19$1@forums-1-dub>
Subject: Re: [ASE] 2k -> 16k migration
Lines: 52
MIME-Version: 1.0
Content-Type: text/plain; format=flowed; charset="UTF-8"; reply-type=response
Content-Transfer-Encoding: 7bit
X-Priority: 3
X-MSMail-Priority: Normal
X-Newsreader: Microsoft Windows Mail 6.0.6002.18197
X-MimeOLE: Produced By Microsoft MimeOLE V6.0.6002.18463
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <507795da$1@forums-1-dub>
Date: 11 Oct 2012 21:00:26 -0700
X-Trace: forums-1-dub 1350014426 172.20.134.152 (11 Oct 2012 21:00:26 -0700)
X-Original-Trace: 11 Oct 2012 21:00:26 -0700, vip152.sybase.com
X-Authenticated-User: TeamSybase
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31426
Article PK: 74315

Marcin,
16k page size may not be best, sometimes 4k or 8k is best...
Many operations happen at the extent level. An extent is 8 pages.

1.I have dealt with some co-workers that told me my san was not buffering at 128k(16k*8).
However my san could handle a 64k (8k*8) read. So you must know your hardware limits!!!!!

2. If filesystems are used for devices then you would use the page size of the file systems.
It is common for a Linux mounted filesystem to have a 4k page size. So you must know your filesystem limits too!!!!!

The improvements are often seen in the single page read operations where the ASE server issues a 2k request but the underlying
os does the work at a 4k or 8k in the lower levels then the os disposes of the extra information that it gathered.


IE:
*** bad case example***ASE asks for a 2k read, the os honored the request as a 4k read, then presented only the requested 2k
back to ASE, that would leave the extra 2k uncached in ASE. (Work done but not used)
***Best case type situation*** If ASE had asked for 4k and the os reads at 4k and sent 4k back to ASE then ASE would have the
whole 4k in ASE cache.
*** Bad case example*** On the flipside, if ASE requested 16k and the os worked at 8k then the os would need to do two
operations to fullfil the 16k request.

FYI - You must also consider the use of text/image pages. Prior to ASE 15.7, a small text/image value will always consume a
whole page... IE: 80 bytes might consume 2k, 4k,8k or 16k based on the page size.


--
Cory Sane
[TeamSybase]
Certified Sybase ASE 15.0 Administrator Associate
Certified Sybase ASE 15.0 SQL Developer Professional

"mnj" <marcin.najs@gmail.com> wrote in message news:5076aa19$1@forums-1-dub...
> Hi.
> Can someone explain if ASE 2k->16k migration
> can improve overall (I/O) database performance (and how):
>
> 1. oltp environment (with small number
> of DSS/Report queries)
> 2. Page 2k
> 3. Data cache (2k & 16k pools (16k-20% of cache size))
> 4. SMP environment (4-8 ASE engines)
> 5. Large number of concurent connections
> 6. Row-level locking scheme
>
> I have never considered migrating to 16k and make
> any tests. Maybe there are some general advantages...
> Any suggestions?
>
> Best Regards
> --
> marcin


mnj Posted on 2012-10-15 12:01:08.0Z
From: mnj <marcin.najs@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: [ASE] 2k -> 16k migration
References: <5076aa19$1@forums-1-dub> <507795da$1@forums-1-dub>
In-Reply-To: <507795da$1@forums-1-dub>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <507bfb04$1@forums-1-dub>
Date: 15 Oct 2012 05:01:08 -0700
X-Trace: forums-1-dub 1350302468 172.20.134.152 (15 Oct 2012 05:01:08 -0700)
X-Original-Trace: 15 Oct 2012 05:01:08 -0700, vip152.sybase.com
Lines: 46
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31437
Article PK: 74326

W dniu 2012-10-12 06:00, Cory Sane [TeamSybase] pisze:

> Marcin,
> 16k page size may not be best, sometimes 4k or 8k is best...
> Many operations happen at the extent level. An extent is 8 pages.
>
> 1.I have dealt with some co-workers that told me my san was not
> buffering at 128k(16k*8).
> However my san could handle a 64k (8k*8) read. So you must know your
> hardware limits!!!!!
>
> 2. If filesystems are used for devices then you would use the page size
> of the file systems.
> It is common for a Linux mounted filesystem to have a 4k page size. So
> you must know your filesystem limits too!!!!!
>
> The improvements are often seen in the single page read operations where
> the ASE server issues a 2k request but the underlying os does the work
> at a 4k or 8k in the lower levels then the os disposes of the extra
> information that it gathered.
>
>
> IE:
> *** bad case example***ASE asks for a 2k read, the os honored the
> request as a 4k read, then presented only the requested 2k back to ASE,
> that would leave the extra 2k uncached in ASE. (Work done but not used)
> ***Best case type situation*** If ASE had asked for 4k and the os reads
> at 4k and sent 4k back to ASE then ASE would have the whole 4k in ASE
> cache.
> *** Bad case example*** On the flipside, if ASE requested 16k and the os
> worked at 8k then the os would need to do two operations to fullfil the
> 16k request.
>
> FYI - You must also consider the use of text/image pages. Prior to ASE
> 15.7, a small text/image value will always consume a whole page... IE:
> 80 bytes might consume 2k, 4k,8k or 16k based on the page size.

Thank you for advice.
We run ASE on RHEL 5/6 (with filesystem page size - 4k) so I will try to
test migration to ASE 4k and make some performance statistics.
Best regards

--
Marcin


Chris Baker [SAP] Posted on 2012-10-19 13:12:21.0Z
From: "Chris Baker [SAP]" <c.baker@sap.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: [ASE] 2k -> 16k migration
References: <5076aa19$1@forums-1-dub> <507795da$1@forums-1-dub> <507bfb04$1@forums-1-dub>
In-Reply-To: <507bfb04$1@forums-1-dub>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <508151b5$1@forums-1-dub>
Date: 19 Oct 2012 06:12:21 -0700
X-Trace: forums-1-dub 1350652341 172.20.134.152 (19 Oct 2012 06:12:21 -0700)
X-Original-Trace: 19 Oct 2012 06:12:21 -0700, vip152.sybase.com
Lines: 51
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31454
Article PK: 74343


On 10/15/2012 8:01 AM, mnj wrote:
> W dniu 2012-10-12 06:00, Cory Sane [TeamSybase] pisze:
>> Marcin,
>> 16k page size may not be best, sometimes 4k or 8k is best...
>> Many operations happen at the extent level. An extent is 8 pages.
>>
>> 1.I have dealt with some co-workers that told me my san was not
>> buffering at 128k(16k*8).
>> However my san could handle a 64k (8k*8) read. So you must know your
>> hardware limits!!!!!
>>
>> 2. If filesystems are used for devices then you would use the page size
>> of the file systems.
>> It is common for a Linux mounted filesystem to have a 4k page size. So
>> you must know your filesystem limits too!!!!!
>>
>> The improvements are often seen in the single page read operations where
>> the ASE server issues a 2k request but the underlying os does the work
>> at a 4k or 8k in the lower levels then the os disposes of the extra
>> information that it gathered.
>>
>>
>> IE:
>> *** bad case example***ASE asks for a 2k read, the os honored the
>> request as a 4k read, then presented only the requested 2k back to ASE,
>> that would leave the extra 2k uncached in ASE. (Work done but not used)
>> ***Best case type situation*** If ASE had asked for 4k and the os reads
>> at 4k and sent 4k back to ASE then ASE would have the whole 4k in ASE
>> cache.
>> *** Bad case example*** On the flipside, if ASE requested 16k and the os
>> worked at 8k then the os would need to do two operations to fullfil the
>> 16k request.
>>
>> FYI - You must also consider the use of text/image pages. Prior to ASE
>> 15.7, a small text/image value will always consume a whole page... IE:
>> 80 bytes might consume 2k, 4k,8k or 16k based on the page size.
>
> Thank you for advice.
> We run ASE on RHEL 5/6 (with filesystem page size - 4k) so I will try to
> test migration to ASE 4k and make some performance statistics.
> Best regards
>

Page sizes aside, if you are using a journalling file system (i.e. EXT4)
instead of raw devices make sure you turn off the journalling features
and don't update the inode access times for the ASE device filesystem (
-noatime, etc) and turn on directio and concurrent I/O.

This can give a huge boost in performance.

Chris


mnj Posted on 2012-10-26 10:21:35.0Z
From: mnj <marcin.najs@gmail.com>
User-Agent: Mozilla/5.0 (Windows NT 6.1; rv:16.0) Gecko/20121010 Thunderbird/16.0.1
MIME-Version: 1.0
Newsgroups: sybase.public.ase.general
Subject: Re: [ASE] 2k -> 16k migration
References: <5076aa19$1@forums-1-dub> <507795da$1@forums-1-dub> <507bfb04$1@forums-1-dub> <508151b5$1@forums-1-dub>
In-Reply-To: <508151b5$1@forums-1-dub>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
NNTP-Posting-Host: vip152.sybase.com
X-Original-NNTP-Posting-Host: vip152.sybase.com
Message-ID: <508a642f$1@forums-1-dub>
Date: 26 Oct 2012 03:21:35 -0700
X-Trace: forums-1-dub 1351246895 172.20.134.152 (26 Oct 2012 03:21:35 -0700)
X-Original-Trace: 26 Oct 2012 03:21:35 -0700, vip152.sybase.com
Lines: 63
Path: forums-1-dub!not-for-mail
Xref: forums-1-dub sybase.public.ase.general:31473
Article PK: 74360

W dniu 2012-10-19 15:12, Chris Baker [SAP] pisze:

> On 10/15/2012 8:01 AM, mnj wrote:
>> W dniu 2012-10-12 06:00, Cory Sane [TeamSybase] pisze:
>>> Marcin,
>>> 16k page size may not be best, sometimes 4k or 8k is best...
>>> Many operations happen at the extent level. An extent is 8 pages.
>>>
>>> 1.I have dealt with some co-workers that told me my san was not
>>> buffering at 128k(16k*8).
>>> However my san could handle a 64k (8k*8) read. So you must know your
>>> hardware limits!!!!!
>>>
>>> 2. If filesystems are used for devices then you would use the page size
>>> of the file systems.
>>> It is common for a Linux mounted filesystem to have a 4k page size. So
>>> you must know your filesystem limits too!!!!!
>>>
>>> The improvements are often seen in the single page read operations where
>>> the ASE server issues a 2k request but the underlying os does the work
>>> at a 4k or 8k in the lower levels then the os disposes of the extra
>>> information that it gathered.
>>>
>>>
>>> IE:
>>> *** bad case example***ASE asks for a 2k read, the os honored the
>>> request as a 4k read, then presented only the requested 2k back to ASE,
>>> that would leave the extra 2k uncached in ASE. (Work done but not used)
>>> ***Best case type situation*** If ASE had asked for 4k and the os reads
>>> at 4k and sent 4k back to ASE then ASE would have the whole 4k in ASE
>>> cac
>>> *** Bad case example*** On the flipside, if ASE requested 16k and the os
>>> worked at 8k then the os would need to do two operations to fullfil the
>>> 16k request.
>>>
>>> FYI - You must also consider the use of text/image pages. Prior to ASE
>>> 15.7, a small text/image value will always consume a whole page... IE:
>>> 80 bytes might consume 2k, 4k,8k or 16k based on the page size.
>>
>> Thank you for advice.
>> We run ASE on RHEL 5/6 (with filesystem page size - 4k) so I will try to
>> test migration to ASE 4k and make some performance statistics.
>> Best regards
>>
>
> Page sizes aside, if you are using a journalling file system (i.e. EXT4)
> instead of raw devices make sure you turn off the journalling features
> and don't update the inode access times for the ASE device filesystem (
> -noatime, etc) and turn on directio and concurrent I/O.
>
> This can give a huge boost in performance.
>
> Chris

Thank you.
Devices are located on ext3 filesystems, directio is turned on for
devices. What do you mean by "concurrent IO" ?. Is this ASE conf.
parameter? (max async i/os per server?)
Best Regards.

--
Marcin