s that
would use shared memory, atomic ops and named objects (e.g. event).
SRWLock is for one process only unfortunately.
Nikolay Samofatov
--
Check out the vibrant tech community on one of the world's most
engaging te
y. There are many filesystems (for example log-structured FS or
compressed FS or "write anywhere" FS like ZFS) that can fail with
out-of-disk space condition on random write.
Nikolay Samofatov
--
Check
ization
instead of lock manager calls to speed things up.
I might do either or both of those things.
What do you think? Is it worthwhile to spend time and effort in this
area? Or better consider NBAK stable and fast enough and addr
(please CC to my GMail
account), as issues with this code will be high priority for me. Or I can delay commit until I have
time to perform 100% code coverage analysis.
Please advise.
Thank you,
Nikolay
On 10/10/2014 04:36 PM, Nikolay Samofatov wrote:
Hello, All!
I have mostly completed my
than welcome at this stage. The code passes some basic testing,
but I plan to test it more.
If you like it, and ask me for it, I might actually commit it to HEAD so that it is not only me who
tests it.
Nikolay Samof
Hello, Alex!
On 09/24/2014 11:06 AM, Alex Peshkoff wrote:
> On 09/22/14 19:50, Nikolay Samofatov wrote:
>
>> The best way to speed it up for small blocks allocation in Firebird 2.5
>> allocation algorithm IMO is
>> to replace BTree with custom array.
>> Number of
cator by default,
you would compromise
this idea.
If you ask me - a version that is 5% slower in simple cases, but scales well is
always better.
Because small users don't care about these extra 5%, but large users will
quickly face scalability
problems.
But on the other side, non-scalable al
or replacing memory manager is very simple task for
existing code base.
Best Regards,
Nikolay Samofatov
--
Slashdot TV. Video for Nerds. Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/
this
is what you want.
Nikolay
On 08/27/2014 03:58 PM, Dmitry Yemanov wrote:
> 26.08.2014 00:29, Nikolay Samofatov wrote:
>> When you converted transaction number from SLONG to TraNumber (ULONG) you
>> didn't take into account
>> that LCK_query_data returns SLON
trings, etc for transaction numbers and this is not correct since
"long" is 64-bit integer
on some platforms and ULONG is "unsigned int" on such platforms. While 64-bit
binary ABI often
protects against problems in such situation this is not guarantied to work
across all platfor
Alex, All,
On 07/22/2014 12:41 PM, Nikolay Samofatov wrote:
> Not so smart people use unsigned 32-bit integers.
... One more note on why using unsigned 32-bit integer in interface is not
perfect choice:
There is no such data type in Java and other higher-level languages.
So what do you prop
Alex,
On 07/22/2014 09:33 AM, Alex Peshkoff wrote:
> On 07/22/14 17:23, Dimitry Sibiryakov wrote:
>> 22.07.2014 15:12, Alex Peshkoff wrote:
>>> OK, but if we want to take into an account systems with 64-bit int the
>>> only solution is artificial types? Like FB_SIZE_T?
>> Yes, but definitely
Alex,
>> 2) Re loop counters: In counter-based loops the best and fastest datatype is
>> "int". It is obviously
>> faster than "unsigned int"/ULONG/FB_SIZE_T, whatever. You can use the latter
>> interchangeably, and
>> this is appropriate for current code base.
> Why is 'int' faster than 'unsig
Dmitry, All,
I am really sorry I broke the build and could not fix it quickly.
My luck has been really bad lately. I will test builds better next time.
My mail client is broken now, so I cannot respond to your letter (I can only
read mail via SF for now).
1) I defined FB_SIZE_T in types_pub bec
de is perfectly valid C++11 (you can use "offsetof" macro for non-POD
"standard-layout"
classes there). NULL pointer tricks that were used by Firebird before always
were "undefined behavior".
Please report if next snapshot fails for you a
at as an existence
proof.
On Wednesday, June 25, 2014, Nikolay Samofatov <mailto:nikolay.samofa...@red-soft.biz>> wrote:
All,
On 06/25/2014 09:41 AM, James Starkey wrote:
> I suggest you investigate garbage collecting intermediate unreachable
record versions, which
wo
Vlad, All,
On 06/25/2014 05:58 PM, Vlad Khorsun wrote:
>> AFAIK, concurrent GC in pre-committed transactions without transaction lock
>> was unsafe, and created
>> permanently broken databases.
>> I believe corruption has become especially apparent after commit intended to
>> fix CORE-3515. I do
All,
On 06/25/2014 09:41 AM, James Starkey wrote:
> I suggest you investigate garbage collecting intermediate unreachable record
> versions, which would
> completely take the sting out of long running transactions. It's not
> difficult for superserver,
> but would be problematic for classic.
mit it for READ_ONLY + READ COMMITTED transactions only. For as long you
don't use returned data
for anything important it is somewhat safe.
With this change, I shall probably set up snapshots for NO_REC_VERSION mode as
well. This will make
this mode completely useless,
All,
On 06/23/2014 03:26 PM, Dmitry Yemanov wrote:
> 23.06.2014 23:15, Leyne, Sean wrote:
>> Actually, without the new behaviour, the engine results are not guaranteed
>> to be correct.
> But the point is that their "correctness" depends on the application
> logic. Lots of applications using RC R
implementation detail of GC algorithm and is
mostly useless for users.
But GC watermark is really interesting, if you want to find out which
transaction inhibits your GC.
Currently, to monitor this counter you need to use fb_lock_print, and this is
not convenient at
Hello, Dmitry!
On 06/23/2014 04:15 AM, Dmitry Yemanov wrote:
> 21.06.2014 01:52, Nikolay Samofatov wrote:
>> I attach patch for this functionality to give you an idea of
>> implementation. It depends on a couple other changes so it doesn't apply
>> to FB2.5 clea
Vlad,
On 06/23/2014 03:11 AM, Vlad Khorsun wrote:
21.06.2014 0:52, Nikolay Samofatov wrote:
Hello, All!
We have encountered subtle errors and data corruptions when using complex
triggers/stored procedures in READ COMMITTED
transactions.
I assume you tell about logical data corruptions
patch for this functionality to give you an idea of implementation. It depends on a couple
other changes so it doesn't apply to FB2.5 cleanly.
Any objections if I start porting this functionality to FB3?
Nikolay Samofatov
Index: builds/install/m
Hello, Vlad!
>> To update offline copy of the database over WAN we use the following
>> procedure in a shall script:
>> - obtain baseline GUID of the database using GSTAT -h
>> - pull changes using SSH+NBACKUP using baseline GUID
> What is the file format where changes are stored ?
The same
ackup for exact this purpose was in the original design,
data formats, etc
although it was never completed. Changes do not affect engine code.
If there are no objections to this design I will ask Dmitry Starodubov to port
this code to FB3 and
submit a patch for integration.
Thanks,
Ni
rch) terabytes of external content as
in our case, memory
consumption becomes impossible even for our machines with 2 TB of RAM on each
node.
All in all, I believe that proper implementation of BLOB lifetime tracking in
Firebird is long overdue.
Nikolay Samofatov
---
processing to function.
I privately discussed this issue with Dmitry and would like to confirm here
that backing out the
patch indeed fixes the problem.
Nikolay Samofatov
--
Everyone hates slow websites. So do we.
Make your
fstat(file->fil_desc,&statistics);
> + if (fstat(file->fil_desc,&statistics) != 0) {
> + unix_error("fstat", file, isc_io_access_err);
> + }
>
> const size_t len1 = sizeof(statistics.st_dev);
> const size_t len2 = sizeof(stat
21 is used.
With default setting LM mutex wait is > 50% and lock manager is the bottleneck.
BTW, we completed the work on 64-bit LM, and can publish sources but we are too
busy with other
issues to actually do the merge now.
--
Nikolay Samofatov, MB
tex operations and copying from file system cache to userspace
emerge as hard bottleneck.
With lock manager change to 64-bit one 24 core node handles ~10 million user
transactions daily.
reliably, at times having >1500 concurrent INSERT/UPDATE requests.
Shall we merge lock manager changes?
N
Alex,
> Taking into an account that most of users do not need>2Gb of lock
> table, 64-bit offsets (at least for 2.5) should better remain tunable
> build parameter, turned off by default.
Great idea, BTW. I haven't thought of a build parameter.
se are the largest systems we
worked on.
8 GB of lock manager space per database should be just enough for them. With
the allocation error
check in place we'll have this problem solved for the next year or two until
larger systems become
port large
installations:
1) Engine should not crash when lock memory size limit is reached, and fail
gracefully instead
2) Various offsets inside lock manager should be made 64-bit?
Nikolay Samofatov
--
Virtualization & Cl
34 matches
Mail list logo
