On Sat, Jan 5, 2013 at 6:12 AM, Dimitry Sibiryakov <s...@ibphoenix.com> wrote:
> 05.01.2013 11:59, Vlad Khorsun wrote:
> > In general, pages are written as result of
> > a) page cache preemption (when new page should be read into cache
> > and least recently used page is dirty)
> > b) precedence writes (when some dirty page is about to be written
> > it forced writes of all pages it dependent on)
> > c) another attachment in CS\SC asks our attachment to release the
> > page lock we own and page is dirty in our local cache
> > d) flush at commit\rollback\end_of_sweep\detach
>
> So, if I understand correctly, if there is a lot of garbage in
> database, sweep with GC
> touch a lot of pages and almost any activity in parallel connections cause
> massive page
> flush. Exactly the behavior observed by TS.
>
Err, no on three counts. The first is that there was no other activity on
the database that demonstrated 1Tb of writes for a 55Gb database. The
second is that even if there were conflicts, that sweep was done by a
SuperServer configuration, so dirty pages do not go to disk when their lock
is released. And finally, even if there were conflicts and it were a
Classic installation, the only time large numbers of pages are forced at
once is on commit. Conflicts are written page by page with the conflicting
process waiting for the write to complete before proceeding.
Best regards,
Ann
------------------------------------------------------------------------------
Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS,
MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current
with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft
MVPs and experts. SALE $99.99 this month only -- learn more at:
http://p.sf.net/sfu/learnmore_122912
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
