Re: [Firebird-docs] Adding new doc "Firebird UDRs in Pascal"

[Alexey Kovyazin (ak) via Firebird-docs]

Hello,

Lets put there IDPL.

Regards,
Alexey Kovyazin


 Денис Симонов via Firebird-docs :

> I don't mind. This article was originally created for general access,
> although I did not think about the license, but if necessary, I can add so
> that there is no contradiction
>
> --
> Regards,
> Simonov Denis.
> вторник, 19 сентября 2023г., 19:02 +03:00 от Mark Rotteveel via
> Firebird-docs firebird-docs@lists.sourceforge.net:
>
> On 19-09-2023 13:12, Köditz, Martin wrote:
> > I have recently translated the document "Writing Firebird UDRs in
> > Pascal" by Denis Simenov into English. If you and Denis agree, I would
> > include both the Russian and English versions in the general
> documentation.
> >
> > What is your opinion about this?
>
> I don't see a problem with it *if* Denis agrees, and if there is a clear
> license for the documentation.
>
> Apart from that, in the future please use firebird-devel
> (https://groups.google.com/g/firebird-devel) also for documentation
> related discussions.
>
> Mark
> --
> Mark Rotteveel
>
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] Outdated documents

[Alexey Kovyazin (ak)]

Hello Mark,

May be we can map page of multi page document to the link of single page
document with anchor?


Regards,
Alexey Kovyazin

пн, 5 июл. 2021 г., 22:09 Mark Rotteveel :

> On 05-07-2021 20:04, Alexey Kovyazin wrote:
> > I just found that we have a hidden nest of old versions of many documents
> >
> > https://www.firebirdsql.org/pdfmanual/html/
> >
> > and many of them seems to be well-ranked by Google :(
> >
> > I think the best solution will be to create mapping through nginx or
> > similar to the actual versions, so it will be seamlessly unified,
> > without many 404 on site.
> > Is it Ok? or could be another solution?
>
> I'll look it over and coordinate with Sergey to add the necessary
> redirects. I'm already maintaining a list of such redirects for
> documentation.
>
> One of the problems is that multi-html documents are probably better for
> search-engine ranking. I'm currently investigating options to
> reintroduce multi-html documents again (at least for the language
> references).
>
> Mark
> --
> Mark Rotteveel
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] Firebird 3.0 Language Reference

[Alexey Kovyazin (ak)]

Hello,

I took a quick look and did not see any noticeable problem.

Regards,
Alexey

вт, 23 февр. 2021 г., 19:27 Mark Rotteveel :

> I'm going to publish the links tomorrow.
>
> Mark
>
> On 20-02-2021 17:02, Mark Rotteveel wrote:
> > I have finished up the first version of the Firebird 3.0 Language
> > Reference, I used the 2.5 version as starting point, and added new
> > things based on the release notes and the Russian Firebird 3.0 Language
> > Reference, and made corrections based on inspecting the actual syntax
> > and close reading of the existing text.
> >
> > Before I put the links up on the website, I'd like another set of eyes
> > on it. Not so much content-wise, as more layout-wise (e.g. weird
> > rendering problems), as by now I'm seeing a bit cross-eyed ;)
> >
> > Links:
> >
> > HTML:
> >
> https://firebirdsql.org/file/documentation/html/en/refdocs/fblangref30/firebird-30-language-reference.html
> >
> >
> > PDF:
> >
> https://firebirdsql.org/file/documentation/pdf/en/refdocs/fblangref30/firebird-30-language-reference.pdf
> >
> >
> > I committed the document as one large commit. Originally, I had it
> > separated out into individual commits, but somewhere along the way I got
> > sidetracked by making consistency changes all over the document, or a
> > change in one part triggered a revision elsewhere, and in the end I gave
> > up on making incremental commits and decided to just use one commit. My
> > apologies to translators for this, but it was the only way to retain my
> > sanity.
> >
> > If you need to diff sources to find out what changed, I recommend taking
> > the Firebird 2.5 Language Reference sources, rename them to match the
> > 3.0 version, and split the DDL and Security chapter in similar fashion
> > as done for the 3.0 version (per keyword or subject).
> >
> > Mark
>
>
> --
> Mark Rotteveel
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] gstat OST - OIT and Sweep

[Alexey Kovyazin (ak)]

Hello Martin,

I spoke with Vlad about section devoted to garbage, and we agreed it is
difficult.

I plan to rewrite it with pictures explaining records versions, garbage and
sweep, but it really needs courage :)

I suggest to let ost-oit phrases as is.


Regards,
Alexey Kovyazin
IBSurgeon




пт, 31 июл. 2020 г., 12:56 Köditz, Martin :

> Hi,
>
>
>
> I’m currently working on gstat-de. I struggled with following part:
>
>
>
> Many web sites, books, manuals (previously including this one) explain
> that the automatic sweep is activated when OAT - OIT is greater than the
> sweep interval.
>
> This is _not_ the case as explained by Vlad Khorsun, one of the Firebird
> developers, who explained that it is when OST -- OIT is greater than the
> threshold that the sweep is activated.
>
>
>
> What does the last sentence exactly mean? Can someone „tidy“ it?
>
>
>
> Regards
>
> Martin
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] Translation of Russian Firebird 3.0 Language Reference

[Alexey Kovyazin (ak)]

Hello,

We did survey in Telegram channel, and idea was to skip 3.0 and do the
translation of LR4.0...


Regards,
Alexey Kovyazin
IBSurgeon

чт, 30 июл. 2020 г., 12:55 Mark Rotteveel :

> On 2020-07-30 09:44, Köditz wrote:
> > Hello everybody,
> >
> > I was asked whether it would make sense to start a crowdfunding
> > campaign for the translation of the Russian Firebird 3.0 Language
> > Reference into English.
> >
> > Or are there already other efforts to implement it?
>
> I'm not sure if that is a viable course of action. IIRC, the translation
> effort for 2.5 cost quite a lot (the initial idea was that the money
> collected would also go toward translating the 3.0 version, but not
> enough was left) and also required a lot of post-translation editing by
> Helen to fix glaring translation errors. I'm considering to spend some
> time to use the current 2.5 version as a basis to go to 3.0 (and then to
> 4.0), where I may use Google translate on the Russian 3.0 version, but
> might also just write things from scratch. However, I haven't made solid
> plans for that yet as I first want to finish up the migration to
> AsciiDoc.
>
> Mark
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] Firebird File and Metadata Security migrated

[Alexey Kovyazin (ak)]

Hello,

I support the idea of the single Page list/index for all docs.

I suggest that we should create such page, and then ask people about their
opinion (it will also increase awareness of documentation).

Regards,
Alexey Kovyazin

ср, 1 июл. 2020 г., 16:31 Paul Vinkenoog :

> Mark Rotteveel wrote:
>
> > I migrated the Firebird File and Metadata Security document.
> (...)
> > I do wonder if this document really belongs under 'Reference Manuals', I
> > think it would be more suitable under White Papers & Presentations..
>
> I think the whole categorization is seriously flawed.
>
> First we have the top-level categories:
>
> - Release Notes
> - Reference Manuals
> - White Papers & Presentations
> - FAQ
> - Firebird Books
> - Drivers Documentation
> - Third-Party Docs and Articles
>
> each corresponding to a separate webpage.
>
> Then within those categories (i.e. on most of those webpages) we have
> further subdivisions. For the page "Reference Manuals", they are:
>
> - Current Versions
> - Firebird Command Line Tools
> - Various User Manuals
> - Reference Material (h? I thought the whole page was Reference
> Manuals)
> - Firebird Licenses
>
> and a couple more.
>
> Given the fact that the bulk of our docs is on the "Reference Manuals"
> page, even if they aren't reference manuals, I think that the Firebird
> File and Metadata Security document is reasonably well placed under
> "Various User Manuals".
>
> Now, this isn't a pressing matter, but I do think that we should have
> the Doc index back on a single page again (except maybe for a few docs/
> categories that are heavily "niche" and/or outdated and/or third-party),
> with categories that make sense, and without separate lines for each
> language version, because that's eating up huge amounts of vertical
> space.
>
> Paul Vinkenoog
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] Conversion of fbutil-*

[Alexey Kovyazin (ak)]

Hello Mark,

I think it is necesary to keep the current structure, and unite them only
virtually, since "command line tools" is a weak basis for grouping such
different tools.
Theoretically, they should be parts of Firebird Admin Guide, but now they
are just pieces.

Another question - do you plan to convert also Developers Guide?


Regards,
Alexey Kovyazin


пн, 15 июн. 2020 г., 21:13 Mark Rotteveel :

> I was planning on converting the fbutil-* documentation next, however I
> was wondering how to approach this. Historically, we have released those
> as individual documentation, while at the same time they were also
> intended to be a single volume (the "Firebird Command Line Utilities"
> book).
>
> Should I convert them individually (and 'throw away' the fbutil-intro,
> fbutil-outro and fbutil-appendix that are only referred from the
> "Firebird Command Line Utilities" book), or should I try to preserve
> this by allowing them to be built as individual books and as a combined
> volume?
>
> I should note that the text in the intro and outro is outdated because
> it wasn't updated for several utilitities that are actually documented
> (like gfix, gstat and isql).
>
> Mark
> --
> Mark Rotteveel
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [Firebird-docs] The single Page for the documentation outline

[Alexey Kovyazin (ak)]

Hello Mark,

Like that Page but with high level table of contents for each document.

Regards,
Alexey Kovyazin


ср, 27 мая 2020 г., 14:25 Mark Rotteveel :

> On 2020-05-27 09:43, Alexey Kovyazin (ak) wrote:
> > Hello All,
> >
> > As you know, Firebird documentation contains a set of documents, and
> > they are grouped in several pages, by the topic or type of documents,
> > like Release Notes, etc.
> >
> > Should we consider build the overall list of the docs and put to the
> > Documentation starting Page?
> >
> > It would be like a big outline. Not like a 100% organized
> > documentation set, of co3, but better than current distributed
> > structure.
> >
> > What do you think?
>
> I'm not sure what you mean. This sounds like what we already have at
> https://firebirdsql.org/en/firebird-rdbms/, that page and its subpages
> is that list as I see it.
>
> Mark
>
>
> ___
> Firebird-docs mailing list
> Firebird-docs@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/firebird-docs
>
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

[Firebird-docs] The single Page for the documentation outline

[Alexey Kovyazin (ak)]

Hello All,

As you know, Firebird documentation contains a set of documents, and they
are grouped in several pages, by the topic or type of documents, like
Release Notes, etc.

Should we consider build the overall list of the docs and put to the
Documentation starting Page?

It would be like a big outline. Not like a 100% organized documentation
set, of co3, but better than current distributed structure.

What do you think?

Regards,
Alexey Kovyazin
___
Firebird-docs mailing list
Firebird-docs@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/firebird-docs

Re: [firebird-support] Off-Topic: Firebird future

['Alexey Kovyazin (ak)' a...@ib-aid.com [firebird-support]]

Hello Stefan,


If Firebird users want to have GUI too, we should consider the options.
The situation now is really different than several years ago, so including
a free GUI to Firebird umbrella now is really a option. For example, at
Firebird Conference there was presentation about RedExpert - GPL license,
multi platform, developed by contributor of Firebird and (since last week)
Platinum sponsor.
I tried its beta on Linux and Windows and it worked far better than thing
included into Postgresql and abandoned FlameRobin.

Of course, we should discuss all aspects before making the decision.

Regards,
Alexey Kovyazin
IBSurgeon



пн, 21 окт. 2019 г., 19:24 Stefan Heymann li...@stefanheymann.de
[firebird-support] :

>
>
>
> > Official or not, we need a simple, up to date, Firebird only, native
> > GUI.
>
> I don't get the point. There are GUI tools readily available
> (IBExpert, Upscene, etc.). If you want to have it for free, like in
> free beer, you can sit down, write it and publish it (that's how free
> software is made ...). The Firebird Project just doesn't have the
> resources to do it. We need the available developers for the database
> core and not for a fancy GUI tool.
>
> Best Regards
>
> Stefan Heymann
>
> 
>

Re: [firebird-support] Scaling Firebird - Azure

['Alexey Kovyazin (ak)' a...@ib-aid.com [firebird-support]]

Hello,

Azure simply does not deliver what it promises - simple test
www.ib-aid.com/dbtest gives results for Azure premium ssd in the lowest
25%, simple CrystalDiskMarks shows awful results too.
Your server is yours, but Azure promises Enterprise grade performance,
without worries abour RAID, ssd, etc - but what we get is far from it, as
well as from money paid for it. On other side, Google Cloud shows
reasonable results in these tests, so why pay for the worst option.
Amazon EC2 with ssd also looks better than Azure in terms of performance,
but seems to be much more expensive than Digital Ocean, Hetzner and even
Google Cloud.



Regards,
Alexey Kovyazin
IBSurgeon

ср, 9 окт. 2019 г., 10:49 'Louis van Alphen' lo...@nucleo.co.za
[firebird-support] :

>
>
> I think it is unfair to say Azure sucks. I have had huge performance
> issues with FB on a normal server with server grade SSDs. My desktop PC
> with spindle HDD outperforms it by an order of magnitude. To date it has
> not been resolved but I suspect it has to do with the RAID controller. The
> same server is very fast with MSSQL.
>
> From: firebird-support@yahoogroups.com [mailto:
> firebird-supp...@yahoogroups..com]
> Sent: Wednesday, 09 October, 2019 08:17
> To: Nagy Szilveszter nagy_szilvesz...@yahoo.com [firebird-support] <
> firebird-support@yahoogroups.com>
> Subject: Re: [firebird-support] Scaling Firebird - Azure
>
> Hello,
>
> In short words, Azure sucks, its so called Premium SSD is worse than the
> cheapest consumer grade ssd.
>
> Try Google Cloud or Amazon, or Hetzner.
>
> Regards,
>
> Alexey Kovyazin
>
> IBSurgeon
>
> пн, 7 окт. 2019 г., 0:20 Rune Horneland rune.hornel...@kravia.net  rune.hornel...@kravia.net> [firebird-support] <
> firebird-support@yahoogroups.com 
> >:
>
> Hi,
>
> We are running Firebird 2 in an Azure VM. It can only take so much in
> terms of concurrent connections.
>
> What top-level advice would you give to scale this?
>
> We are connecting to it from a .NET core Middleware using Azure VMs.
>
> The architecture of the middleware is quite monolithic. We are considering
> rewriting it with Microservices and Azure functions or similar architecure,
> but are unsure how we could scale the Firebird DB or connections itself.
>
> Multiple casehandlers in our company use it via a Delphi-based Windows
> application at the other end, with a vendor maintaining the Firebird DB and
> Windows app development, so we are locked into using Firebird.
>
> RUNE HORNELAND
> CTO
>
> [Non-text portions of this message have been removed]
>
> 
>

Re: [firebird-support] Scaling Firebird - Azure

['Alexey Kovyazin (ak)' a...@ib-aid.com [firebird-support]]

Hello,

In short words, Azure sucks, its so called Premium SSD is worse than the
cheapest consumer grade ssd.

Try Google Cloud or Amazon, or Hetzner.

Regards,
Alexey Kovyazin
IBSurgeon




пн, 7 окт. 2019 г., 0:20 Rune Horneland rune.hornel...@kravia.net
[firebird-support] :

>
>
> Hi,
> We are running Firebird 2 in an Azure VM. It can only take so much in
> terms of concurrent connections.
> What top-level advice would you give to scale this?
>
> We are connecting to it from a .NET core Middleware using Azure VMs.
> The architecture of the middleware is quite monolithic. We are considering
> rewriting it with Microservices and Azure functions or similar architecure,
> but are unsure how we could scale the Firebird DB or connections itself.
> Multiple casehandlers in our company use it via a Delphi-based Windows
> application at the other end, with a vendor maintaining the Firebird DB and
> Windows app development, so we are locked into using Firebird.
>
>
> *RUNE HORNELAND*CTO
>
> 
>

Re: [firebird-support] Re: Does gbak use WireCompression?

['Alexey Kovyazin (ak)' a...@ib-aid.com [firebird-support]]

Martin,

Vlad head read my mind and answered :)
Try remote restore through service manager, it is much faster.

Regards,
Alexey Kovyazin

вт, 17 сент. 2019 г., 9:59 hv...@users.sourceforge.net [firebird-support] <
firebird-support@yahoogroups.com>:

>
>
> ---In firebird-support@yahoogroups.com,  wrote :
>
> > I often perform restores on remote servers via WAN. Since this sometimes
> takes a long time, I wonder if gbak > takes into account the parameter
> WireCompression. What needs to be set as where?
>
>   gbak is usual client application, it needs no special actions to use
> WireCompression. Just put zlib1.dll near the fbclient.dll and set
> WireCompression = true at client side (using firebird.conf or DPB). Make
> sure zlib1.dll is present at server side also.
>
>   But much more efficient way to do restore via slow network is remote
> backup\restore (see CORE-2666).
> Read doc\README.services_extension chapter (4) for details.
>
> Regards,
> Vlad
>
>
> 
>

Re: [firebird-support] gbak of encrypted database

['Alexey Kovyazin (ak)' a...@ib-aid.com [firebird-support]]

Hello,

 gbak does not support encryption in the standard Firebird 3.0
distribution.

In IBSurgeon's plugin implementation there is a gbak support,  with
transparent encryption of backups with the same key.
https://ib-aid.com/en/firebird-encryption-plugin-framework/

And restored database from the encrypted backup is also encrypted,
otherwise it will be a security hole.

If you're implementing your own plugin,  you can implement whatever you
need.

Regards,
Alexey Kovyazin
IBSurgeon



вт, 1 мая 2018 г., 3:24 Hamish Moffatt ham...@risingsoftware.com
[firebird-support] :

>
>
> If a db is encrypted with Firebird 3 encryption, is a backup made with
> gbak also encrypted?
>
>
> https://www.firebirdsql.org/file/community/conference-2016/encrypting-firebird-databases.pdf
> implies you need to encrypt your backup afterwards so that means no.
>
> Will a restored db from that backup be encrypted automatically or would
> you have to run 'ALTER DATABASE ENCRYPT ...' on the new db afterwards if
> you want it encrypted also?
>
> thanks
>
> Hamish
>
> 
>

Re[2]: [firebird-support] How to change cpu utilization in Firebird engine?

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi,
There is no sense to tune or upgrade CPU or other hardware without prior 
analysis of slowness reasons.
In 95% the reason is in non-optimal queries plans or absense of indices. 
--
Regards,
Alexey Kovyazin
IBSurgeon суббота, 07 января 2017г., 11:26 +03:00 от trsk...@yahoo.com 
[firebird-support]  firebird-support@yahoogroups.com :

> 
>Thanks for your clarification.
>
>I was planning to upgrade my cpu with a used Xeon 2683 V3 (price on my country 
>is about the same with I7 6700K), but it has 14 cores & 35MB L3 cache.
>
>So, I guess, a single connection in Firebird 3.0 will running poorly on Xeon 
>2683 V3, it will only utilized about 7% cpu. I have to re evaluate again this 
>plan.
>
>Btw, if there are 6 connection on 4 cores, how is cpu utilization calculate?
>
>Thanks & regards,
>Anto.
>

[firebird-support] Re: FB Conference 2016

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi Andre!
Thank you! Have a good vacation! 
We will definetely do more conferences and meet there!
--
Regards,
Alexey Kovyazin
IBSurgeon пятница, 07 октября 2016г., 09:53 +02:00 от André Knappstein  
andre.knappst...@beta-eigenheim.de :

>Hello Alexey,
>hello Dmitry,
>
>I  hope  the  conference is going well, and that all of you personally
>also are well!
>
>I've  been  looking forward to the conference so much, but some months
>ago it turned out, that - starting from today - this would be the only
>chance  for  my  wife  and  me  to  have  at least one week of holiday
>together.
>
>So I could unfortunately not come to Prague this time.
>
>But I am looking forward to the next conferences, and maybe there will
>be a chance for a firebird tour with seminar or similar.
>
>Have a great time in Prague!
>
>best regards from Germany,
>André Knappstein
>
>
>mit freundlichen Grüßen,
>
>ppa. André Knappstein
>EDV und Controlling
>~~
>beta Eigenheim- und Grundstücksverwertungsgesellschaft mbH
>Hafenweg 4
>59192 Bergkamen-Rünthe
>
>Telefon: +49 2389 9240 140
>Telefax: +49 2389 9240 150
>e-mail:  andre.knappst...@beta-eigenheim.de
>
>Amtsgericht Hamm Nr. B 420
>Geschäftsführer: Achim Krähling, Dirk Salewski und Matthias Steinhaus
>
>USt-IDNr.: DE 125215402
>

Re: [firebird-support] Slow Firebird performance in Azure with durable data disks (e.g., Premium Storage)

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi Antti,
Try to lock database with nbackup and check the peformance with locked database 
- in this case all writes will go to delta file sequentially.
If your assumption is true and Premium Storage does not work good with random 
writes, you will see less decrease of performance.
Also, there are other options to deal with such performance problem - please 
contact me directly.
--
Regards,
Alexey Kovyazin
IBSurgeon вторник, 30 августа 2016г., 19:18 +03:00 от Antti Nivala 
antti.niv...@m-files.com [firebird-support]  firebird-support@yahoogroups.com :

> 
>Hi,
> 
>We've experimented with the performance of Firebird in virtual machines in 
>Microsoft's Azure cloud. With Azure VMs, any durable data needs to be placed 
>in "data disks", and essentially that means network-connected storage that is 
>inherently
 slower than e.g. local SSD disks.
> 
>When testing our application's operations with a Firebird database that's on 
>such a "data disk", the performance is roughly 6x slower than when the 
>database is on the VM's local, temporary-only disk. The temporary disks 
>obviously are not
 good for real use so this is for performance comparison only.
> 
>When we do the same test with SQL Server (e.g., SQL Server Express Edition), 
>the performance difference between the temporary local disks and the durable 
>data disks is significantly smaller. SQL Server seems to perform pretty much 
>as fast
 with the data disk with our application's operations.
> 
>The way I'm explaining this difference to myself is that Firebird's way of 
>making the transactions durable is not well suited for this kind of 
>environment where the disk has latency. As far as I understand, Firebird needs 
>to make a lot
 of page writes to the disk to different locations (as the transaction is 
touching multiple tables), and this is probably poison in a situation where the 
disk has latency. On the other hand, SQL Server, as far as I understand, only 
needs to write to its transaction
 log file to make the transaction durable, which is probably an advantage in 
this kind of hardware setup.
> 
>Do you think these general observations/reasons for the slow performance with 
>Firebird with Azure data disks are correct?
> 
>Is there anything obvious that we could do to make Firebird work fast in Azure 
>VMs (requiring durability of the transactions, of course, so turning forced 
>writes off doesn't sound like an option)?
> 
>I can't think of anything myself, but I wanted to ask before completely 
>disregarding the option of running Firebird in Azure VMs.
> 
>More info on Azure Premium Storage data disks here:
>https://azure.microsoft.com/en-us/documentation/articles/storage-premium-storage/
> 
>Antti
> 
>

Re: [firebird-support] Issue with Database Cache Size on FB 3.0

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi Fabian,
Firebird caches only actually used pages.
The small cache means that your application touches the small part of the 
database.
--
Regards,
Alexey Kovyazin
IBSurgeon
PS It is difficult and wrong to give you any direct advice without all details 
in hands - it can lead to worse performance than with default parameters.
среда, 01 июня 2016г., 04:16 +03:00 от Fabian Ernesto Chocron 
fabia...@itbizolutions.com.au [firebird-support]  
firebird-support@yahoogroups.com :

> 
>Hi All
>
>We are having trouble setting up the database cache size on FB 3.0 
>running on Windows 2008 R2 64 bits with 32 GB ram.
>
>The problem we have is we cannot get the server to allocate the ram for 
>the cache as we intend. With FB 2.54 we had the DB cache set very high, 
>close to 1 GB per database, all running in RAM memory. With FB 3.0 we 
>read it can allocate much more RAM to the cache, but it appears the 
>server is allocating very small amount of Ram when the first user 
>connects to the DB, and as we connect more users to the DB the ram 
>consumption increases slowly. The setting we are playing with are:
>
>On firebird.conf
>
>FileSystemCacheThreshold = 0
>FileSystemCacheSize = 17179869184 (this is 16 GB - the server has 32 GB 
>ram.)
>
>On databases.conf
>
>MyTestDB = c:\Temp\MyDb.fdb
>{
>DefaultDbCachePages = 458752
>}
>
>Any ideas what could be wrong? Or what settings would give us maximum 
>RAM usage for the DB cache (we dont want file system cache meaning HDD 
>cache, we want to have the DB in RAM for the purpose of reading the DB)
>
>Cheers,
>Fabian
>
>

[firebird-support] Re[2]: [FB 2.1] Firebird engine seems to slow down on high load without utilizing hardware

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Patrick,
Definetely you need to compare real life loads.
--
Regards,
Alexey Kovyazin
IBSurgeon среда, 13 апреля 2016г., 04:47 +03:00 от " thetr...@yahoo.com 
[firebird-support]" < firebird-support@yahoogroups.com> :

> 
>
>Hey Alexey,
>thanks you for our input. I think what you say is correct, and we reviewed our 
>disk setup again.
>We are utilizing mechnical discs so it's kinda hard to compare SSD performance 
>to them.
>But they should provide enought IOPS for our load.
>
>Unfortunatly we can't just switch to a single SSD, since we would loose 
>replication and failover systems the SAN provides which is a critical demand 
>for us. I'm afraid for now we have to stick with it, until we have some facts 
>to proof that the SAN Setup is our limiting factor. And data is not should 
>that for me currently.
>
>On a sidenode, we do own a server with SSD setup, but in tests we couldn't get 
>a noticable performance gain through increasement of IOs this way. (tests was 
>generic and not real world load unfortunatly)
>
>Best Regards,
>Patrick
>
>---In firebird-support@yahoogroups.com,  wrote :
>
>Hi Patrick,
>
>If you say that problem occurred recently, I would suggest you to
check SAN disks health.
>
>However, these values
>>> Average system IOPS under load read: 100
>>>Average system IOPS under load write: 550
>>> Backup Restore IOPS read: 1700
>>> Backup Restore IOPS write: 250
are really, really low. 
>1700 IOPS for the database with 4k page means 6.8Mb/sec (in case
of random reads).
>
>I suggest to install a single SSD drive and check how it will
work.
>SSD IOPS looks like
>  Random Read 4KB (QD=32) :   283.050 MB/s [ 69104.0 IOPS]
>  Random Write 4KB (QD=32) :   213.837 MB/s [ 52206.2 IOPS]
>
>
>From our optimization practice we found that if you need to
optimize only the single instance of the database, the most cost
effective way is to upgrade to SSD first, and only then fix other
problems.
>
>Regards,
>Alexey Kovyazin
>IBSurgeon HQbird  www.ib-aid.com
>
>
>
>>> 
>>>hi,
>>>recently we had some strange performance issues with our
Firebird DB server.
>>>On high load, our server started to slow down. Select and
update SQL query times did go up by more than 500% on
average,
>>>but reaching unreasonable high execution times at worst
case. (several minutes instead of < 1sec)
>>>
>>>OIT/OAT/Next Transaction statistics was within 1000 the
hole time
>>>We were not able to messure any hardware limiting factor.
Indeed, this system was running with only 8 cores at about
70% CPU usage on max. load.
>>>We decided that this may be our problem since we
experienced a similar problem at about 80% CPU load in the
past.
>>>So we upgraded the hardware. As expected, the CPU-load
dropped to ~35% usage on max. load scenario.
>>>But this did not solve the problem.
>>>Same story for the harddisk system. The usage is not even
near it's max capacity.
>>>
>>>We also can't see any impact on the harddisk.
>>>We'r kind of stuck with our ideas, because we have no
idea what could be a potential bottleneck to the system.
>>>Since the hardware doesn't show a limit, there have to be
anything else - most likely firebird engine related that's
limiting our system.
>>>We would be very grateful if anyone can give us hints
where we can search further.
>>>Or someone has similar experiences to share with us.
>>>
>>>
>>>Operating System: Windows Server 2003
>>>Firebird: 2.1.5 Classic
>>>Dedicated database server (VMWare)
>>>
>>>CPU: 16 cores, each 2.4 GHz
>>>RAM: 32 GB
>>>About
14GB are used from OS and firebird processes under max
load.
>>>HDD: SAN Storage System
>>>
>>>Average
system IOPS under load read: 100
>>>Average
system IOPS under load write: 550
>>>Backup
Restore IOPS read: 1700
>>>Backup
Restore IOPS write: 250
>>>SAN
IPOS Limit (max): 3000
>>>
>>>Firebird Config Settings, based on defaults
>>>DefaultDbCachePages
= 1024
>>>LockMemSize
= 134247728
>>>LockHashSlots
= 20011
>>>Database
>>>size:
about 45 GB
>>>450
to 550 concurrent connections
>>>Daily
average of 65 transactions / second (peak should be
higher)
>>>
>>>FB_LOCK_PRINT (without any params) while system was
slowing down (~4 days uptime).
>>>I have to note, Firebird was not able to print the
complete output (stats was not cropped by me)
>>>
>>>LOCK_HEADER BLOCK
>>>Version:
16, Active owner:      0, Length: 134247728, Used:
82169316
>>>Semmask:
0x0, Flags: 0x0001
>>>Enqs:
4211018659, Converts: 10050437, Rejects: 9115488, Blocks:
105409192
>>>Deadlock
scans:   1049, Deadlocks:      0, Scan interval:  10
>>>Acquires:
4723416170, Acquire blocks: 640857597, Spin count:   0
>>>Mutex
wait: 13.6%
>>>Hash
slots: 15077, Hash lengths (min/avg/max):    3/  12/  25
>>>Remove
node:      0, Insert queue:     36, Insert prior: 74815332
>>>Owners
(456): forward:
131316, backward: 14899392
>>>Free
owners (9): forward:
39711576, backward: 49867232
>>>Free
locks (42409): forward:
65924212, backward: 23319052
>>>
>>>With best Regards,
>>>
>>>Patrick Friessnegg
>>>Synesc GmbH
>

[firebird-support] Re[2]: [FB 2.1] Firebird engine seems to slow down on high load without utilizing hardware

[Alexey Kovyazin (ak) a...@ib-aid.com [firebird-support]]

Hi,
You wrote:
>The thing is, sure this numbers look really low. But >the system never uses 
>it. The monitoring of the >SAN show's that this load's are never used
You are confusing the reason and the result.
Monitoring shows low numbers because spinning drives cannot provide fast enough 
random reads. 
>From Sintatica, every 20 Minutes a Peak in GC for >~15.000 transactions
Sinatica uses really strange terms to describe transactions behaviour, and 
since it is an abandonen tool, nobody can explain how they are aligned with 
real situation.
--
Regards,
Alexey Kovyazin
IBSurgeon среда, 13 апреля 2016г., 05:08 +03:00 от " thetr...@yahoo.com 
[firebird-support]" < firebird-support@yahoogroups.com> :

> 
>Hey Thomas,
>thanks for your extensive reply.
>Unfortunatly we'r still bound to some old 32bit UDF functionality which we 
>can't get in 64bit. 
>I think you know about the use of SuperClassic with 32bit Server - 2GB RAM 
>Limit :)
>It's not impossible, but also not really a fast route we can go. But for sure 
>again a reason to talk about moving the switch to 2.5.
>
>We did ran some some disk IO benchmarks (with AS SSD) today, and in times of 
>SSD kinda depressing :D
>The thing is, sure this numbers look really low. But the system never uses it. 
>The monitoring of the SAN show's that this load's are never used. The 
>Single-4k-read is worring me, but i lean towards that our 500 proceses are 
>more like the 64-thread test. But even then, we only messured 100 Iops reading 
>on livesystem.
>
>Sequential Read speed: ~ 450 MB / s
>Sequential Write speed: ~500 MB / s
>4k read: 196 Iops
>4k write: 1376 Iops
>4k-64 thread read: 15945 Iops
>4k-64 thread write: 7361 Iops
>
>
>Garbage Info still needs to be collected.
>But first signs show that this indeed could be a potential problem.
>From Sintatica, every 20 Minutes a Peak in GC for ~15.000 transactions. This 
>get's fixed by the server in the relative small amount of time (i think < 1 
>minute), since it's really only a single peak in the graph everytime.
>When the GC stop increasing and the server starts to collect it, we see an 
>increase of concurrent running transactions (= transactions are longer open 
>and processed slower).
>
>We don't have data from the live system yet to see if this behaviour kind of 
>"snowballs" when there is really high load on the server.
>
>Best Regards,
>
>---In firebird-support@yahoogroups.com,  wrote :
>
>Hi Patrick,
>
>>> Hi Thomas, nice to get a response from you. We already met in ~2010 in Linz 
>>> at
>>> your office :)
>>> (ex. SEM GmbH, later Playmonitor GmbH)
>>
>I know. XING (Big Brother) is watching you. Nice to see that you are still 
>running with Firebird. ;-)
>
>
>>> First, sorry for posting a mixed state of informations. The config settings 
>>> i
>>> postet are the current settings.
>>> But the Lock-Table-Header was from last saturday (day of total system 
>>> crash) -
>>> we changed Hash Slot Value since than, but it didn't work. New Table looks
>>> like:
>>> 
>>> 
>>> LOCK_HEADER BLOCK
>>> Version: 16, Active owner:  0, Length: 134247728, Used: 55790260
>>> Semmask: 0x0, Flags: 0x0001
>>> Enqs: 1806423519, Converts: 4553851, Rejects: 5134185, Blocks: 56585419
>>> Deadlock scans: 82, Deadlocks:  0, Scan interval:  10
>>> Acquires: 2058846891, Acquire blocks: 321584126, Spin count:   0
>>> Mutex wait: 15.6%
>>> Hash slots: 20011, Hash lengths (min/avg/max):0/   7/  18
>>> Remove node:  0, Insert queue:  0, Insert prior:  0
>>> Owners (297): forward: 385160, backward: 38086352
>>> Free owners (43): forward: 52978748, backward: 20505128
>>> Free locks (41802): forward: 180712, backward: 3620136
>>> Free requests (-1097572396): forward: 46948676, backward: 13681252
>>> Lock Ordering: Enabled
>>> 
>>> 
>>> The Min/Avg/Max hash lengths look better now, but as you mentioned the Mutex
>>> wait is worring us too.
>>> We have 2 direct questions about that.
>>> 
>>> 
>>> 1) What are the negative effects of increasing Hash-Slots (too high)?
>>
>It somehow defines the initial size of a hash table which is used for lock(ed) 
>object lookup by a key (= hash value), ideally with constant O(1) run-time 
>complexity. If the hash table is too small, due to a too small value for hash 
>slots, it starts to degenerate into a linked/linear list per hash slot. Worst 
>case resulting in O(n) complexity for lookups. The above 20011 setting shows 
>an AVG hash length which looks fine.
>
>As you might know, Classic having a dedicated process per connection model 
>somehow needs a (global) mechanism to synchronize/protect shared data 
>structures across these processes via IPC. This is what the lock manager and 
>the lock table is used for.
>
>>> 2) As far as we know, we can't influence Mutex wait directly (it's just
>>> informational). But do you think that's the reason the underlying hardware 
>>> is
>>> not utilized?
>>
>I don't think you are disk IO bound. Means, I'm not convinced that faster IO