Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Cache Hibernation

10 views
Skip to first unread message

Markus KARG

unread,
Aug 15, 2008, 9:00:41 AM8/15/08
to
A well-filled cache is a fine thing. It holds exactly that data that was
used recently, so you could suppose that the same data is useful to fulfil
the next requests. You do not need to access the database for the
most-requested queries. Unfortunately, the cache content is lost in case of
a server restart. So all the information about what "most-requested data"
means, is gone. That's a pity! It would be great if the cache could be
preserved, so it survives server restarts. An idea would be: "Cache
Hibernation".

My proposal is to add a new command line option to dbsrv12.exe that enables
"Cache Hibernation". If not given, the feature is disabled and dbsrv12.exe
behaves just like dbsrv11.exe (for backwards compatibility). If given, the
feature is enabled and will work like this:

* When shutting down dbsrv12.exe, a hibernation file will be written
containing the page IDs of all pages found in the cache.
* When starting up dbsrv12.exe, if such a hibernation file is found, the
cache will load that page IDs from the databases that are found in the file.

As a result, shutdown and startup will be a bit more time consuming. On the
other hand, the cache will be filled with exactly the most-requested data
from the time of shutdown, and people can go on working without performance
penalties at runtime.

This would be a great feature, since several customers of us demanded this.
They want to wait longer at startup and shutdown in trade of uninterrupted
runtime. If anybody supporting this idea, please comment in the forum. :-)

Certainly in future this opens room to more sophisticated cache management.
For example, a statistic could be done how often what pages are loaded, or
together with what other pages. When beeing idle, the server can then unload
seldomly needed pages and instead load often loaded pages, or pages directly
related (like next / previous page, or like pages containing referenced
rows). Such kind of proactive cache management in idle time would be an
interesting thing, because loading from disk is always a pain, even with
modern, fast disks.

Regards
Markus


Josh Savill

unread,
Aug 15, 2008, 9:18:30 AM8/15/08
to
Markus,

A similar feature already exists in SQL Anywhere and has been in the
product for a while (since ASA 9.0.1). It's called Cache Warming:

http://dcx.sybase.com/index.php#http%3A//dcx.sybase.com/1100en/dbusage_en11/perform-s-4988196.html


--
Joshua Savill
Sybase iAnywhere - Product Manager

Mark Culp

unread,
Aug 15, 2008, 9:53:09 AM8/15/08
to
John, the current Cache Warming implementation loads the database pages
that were loaded the last time that the database was _started_.
Markus is requesting that the cache be preloaded with the pages that
existed when the database was last _shutdown_.

This is an interesting idea, and we are considering it.

Markus: Thank you for making the suggestion.
--
Mark Culp
SQLAnywhere Research and Development
iAnywhere Solutions Engineering
-------------------------------------------------------------------------
-- SQL Anywhere Blog Center - http://www.sybase.com/sqlanyblogs
-- SQL Anywhere Developer Community:
-- http://www.sybase.com/developer/library/sql-anywhere-techcorner
-------------------------------------------------------------------------

Markus KARG

unread,
Aug 18, 2008, 5:55:57 AM8/18/08
to
Mark,

thanks for the explanation, so finally Sybase understood me (was a long
discussion on sybase.public.sqlanywhere until this point). :-)

Would be great if this could be added to SQL Anywhere 12. :-)

Regards
Markus

"Mark Culp" <reply_to_newsgroups_only...@iAnywhere.com>
schrieb im Newsbeitrag news:48A58A3D...@iAnywhere.com...

Markus KARG

unread,
Aug 18, 2008, 5:55:02 AM8/18/08
to
Josh,

this is not true. As discussed already on sybase.public.sqlanywhere, that
existing feature does not result in the same benefit. My proposal will
result in the fact that people can go on working with *the same* data that
was cached when the server was stopped (so the cache still is *hot*).
Instead, the existing proposal will fill up the cache with the same data
that was first queried at the last *boot* time (what nobody cares for, since
it is not the data that people worked with when shutting down). See the
difference?

Regards
Markus

"Josh Savill" <no_spam...@ianywhere.com> schrieb im Newsbeitrag
news:48a58226$1@forums-1-dub...

0 new messages