Hawkin
/
arangodb
mirror of https://gitee.com/bigwinds/arangodb
1
0
Fork 0
Code Issues Projects Releases Wiki Activity
25,551 Commits 358 Branches 495 Tags 994 MiB
Commit Graph

13 Commits

Author SHA1 Message Date
Jan Steemann 9046e1831b clang-format 2016-01-27 13:43:46 +01:00
Jan Steemann 3ad20c0cae auto-generated headers 2016-01-06 18:41:51 +01:00
Jan Steemann a3b026d9d1 removed useless sections from code, unified include guards 2016-01-06 14:15:22 +01:00
Jan Steemann 9a1d7959e9 merged string-buffer.h and StringBuffer.h 2016-01-06 13:24:09 +01:00
Jan Steemann f422576ee0 clang-format 2016-01-05 17:43:24 +01:00
Jan Steemann 4494b69f8e fix compiler warnings on 32bit 2015-09-02 14:13:27 +02:00
Jan Steemann 2e617ac0cc Merge branch 'american-english' of https://github.com/CoDEmanX/ArangoDB into devel 
Conflicts:
	arangod/Wal/Slots.cpp
	lib/Basics/debugging.cpp
	lib/Basics/files.cpp
 2015-09-02 13:14:49 +02:00
Jan Steemann a80d6635ab create fat datafiles 
This prevents SIGBUS when a sparse datafile is accessed and the disk is full. In
this case the mmapped region is not necessarily backed by physical memory, and
accessing the memory may crash the program
 2015-09-02 10:18:24 +02:00
CoDEmanX 956b396e43 Change spelling of 'initialize' to American English (actual code and files) 2015-09-01 17:29:22 +02:00
Jan Steemann e8505a35f2 cppcheck 2015-08-26 21:35:57 +02:00
Max Neunhoeffer c0f1b72bab Add "sensible" madvise calls. 
Essentially the strategy is: A newly created and a newly opened file
is advised to be "SEQUENTIAL ACCESS", because we will either write to
it or scan it sequentially. As soon as it is sealed, we switch the
advice to "RANDOM ACCESS", because this should be the normal pattern and
aggressive read-aheads tend to be bad. The collector and the compactor
switch a sealed file back to "SEQUENTIAL ACCESS" just before they scan
it and back to "RANDOM ACCESS", when they are done.

Furthermore, all data files in a collection are advised with "WILLNEED"
just before the collection is scanned during loading.

Finally, the actual hash table of AssocMulti is advised to be random
access, although this is an anonymous map given to us by malloc and not
a memory mapped file.
 2015-08-26 16:45:26 +02:00
Jan Steemann 7e4b615248 simplify call to mmap 2015-07-27 16:24:25 +02:00
Jan Steemann 506936dcdb rename orgy 2014-09-13 02:35:13 +02:00