Odi's astoundingly incomplete notes
New entriesCode
back | nextMake very sure Oracle uses async IO on Linux
A default installation of Oracle on Linux will use synchronous IO. You have to explicitly enable asynchronous IO by setting a parameter (sic!):
and restart Oracle. If you don't do that then synchronous IO during logfile switches / checkpoints will cause unnecessary waits: log file switch (checkpoint incomplete). At the same time Oracle DBW process will not saturate IO. Your DB will become barely usable during those times.
ALTER SYSTEM SET FILESYSTEMIO_OPTIONS=SETALL SCOPE=SPFILE;and restart Oracle. If you don't do that then synchronous IO during logfile switches / checkpoints will cause unnecessary waits: log file switch (checkpoint incomplete). At the same time Oracle DBW process will not saturate IO. Your DB will become barely usable during those times.
As this also enables direct writes (which circumvent the OS page cache) you must also ensure that the SGA size is close to the RAM size (70-80%). Do not enable the parameter above for small SGAs (< 4GB).
Add comment
package.keywords becomes package.accept_keywords
As of
sys-apps/portage-2.3.89 Gentoo installations must rename /etc/portage/package.keywords to /etc/portage/package.accept_keywords.Relaying SIGINT signal to child processes
Here is a bash function (plus test program) that correctly relays important signals to child processes. So that pressing Ctrl-C reliably terminates both all child processes and the parent process.
- Delivers interrrupt signals also to parent process again (after removing signal handler)
- SIGPIPE is only sent to children
- Works for any number of child processes
- Does not work for SIGKILL (no signal is delivered to app in that case)
#!/bin/bash
relay() {
PIDS=""
for PID in $(pgrep -P $$); do
PIDS="${PIDS} ${PID}"
done
trap "kill -PIPE ${PIDS}" PIPE
PIDS="${PIDS} $$"
#echo "setting up traps to ${PIDS}"
trap "trap - HUP; kill -HUP ${PIDS}" HUP
trap "trap - INT; kill -INT ${PIDS}" INT
trap "trap - QUIT; kill -QUIT ${PIDS}" QUIT
trap "trap - TERM; kill -TERM ${PIDS}" TERM
}
(sleep 10; echo '1st subshell was not killed')&
relay $!
(sleep 10; echo '2nd subshell was not killed')&
relay $!
echo 'please hit Ctrl-C within 10s'
sleep 10
wait
echo 'main shell was not killed'
Fix Firefox Password suggestions
If you have many saved passwords in Firefox's Password Manager then the password suggestions on login forms can become unusably long.
To restore the previous behaviour, in about:config set
To restore the previous behaviour, in about:config set
signon.includeOtherSubdomainsInLookup to false.linux-5.5 mm looks very good
My tests with the upcoming Linux kernel are looking very promising. For me memory management issue has been improved a lot. In recent 5.x kernels the mm would trigger a lot of reclaim scans even with low memory pressure. For example on a 2GB laptop the Normal zone is quite small. Most memory is in the DMA32 zone. And those kernels would trigger reclaim and even swap when opening a browser or using gitk on the kernel repo. Even though there is still plenty of usable RAM.
With 5.5 this is resolved. Reclaim scans are rare again and swap is not used in these situations.
With 5.5 this is resolved. Reclaim scans are rare again and swap is not used in these situations.
A guide to kernel config
Gentoo updating gcc, mpfr, mpc
When Gentoo updates gcc together with mpfr and mpc the normal emerge procedure will cause building of gcc twice. Because mpfr and mpc cause automatic rebuild of the (existing) gcc. But if you are going to update gcc anyway then this is utterly pointless waste of energy.
Instead you can
After gcc update don't forget to switch to the new compiler with
Instead you can
emerge --ignore-built-slot-operator-deps=y -1uav mpfr mpc first without doing the rebuild. This leaves you with a broken gcc maybe (but actually probably not because portage preserves the old library versions), but next you simply emerge -1uav gcc anyway.After gcc update don't forget to switch to the new compiler with
gcc-config and rebuild libtool.Gentoo replacing ntp, vixie-cron, man
Gentoo is cleaning out its closet. It has removed unmaintained upstream packages which were still popular: ntp, vixie-cron and man. Of course it's a logical step and using the modern replacements is rational.
For net-misc/ntp, use net-misc/ntpsec: This has way more robust configuration while eliminating ancient obscure features like traps.
For vixie-cron, use sys-process/cronie. It also itegrates anacron, so you get two in one.
For man, use man-db which is faster as it uses a BDB backend instead of text files.
For net-misc/ntp, use net-misc/ntpsec: This has way more robust configuration while eliminating ancient obscure features like traps.
For vixie-cron, use sys-process/cronie. It also itegrates anacron, so you get two in one.
For man, use man-db which is faster as it uses a BDB backend instead of text files.
Java and its use of filesystem syscalls
File f = new File("build.xml");
// openat(AT_FDCWD, "build.xml", O_RDONLY) = 96
// fstat(96
InputStream io = new FileInputStream(f);
// read(96
io.read();
// read(96
io.read();
// close(96)
io.close();
Path p = f.toPath();
// openat(AT_FDCWD, "build.xml", O_RDONLY) = 96
io = Files.newInputStream(p);
// read(96
io.read();
// read(96
io.read();
// close(96)
io.close();
The NIO way of creating an input stream from a file actually saves an fstat syscall.ipset's hashsize and maxelem parameters
When defining a Linux hash ipset the parameters hashsize and maxelem must be chosen.
maxelem is easy: this limits how many entries the ipset can have.
hashsize however is a tuning parameter. It defines how many hash buckets are allocated for the hashtable. This is the amount of memory that you are willing to sacrifice. It has a very coarse granularity and accepts only values that are equal to 2^n where n is 1..32.
Hashtables are most efficient (buckets mostly contain only a single key, eliminating the search within a bucket) when only 3/4 of their buckets are actually used (1/4 is free). But for large ipsets this is not practical as it would waste a lot of memory. For example for an ipset with 100'000 entries the hashsize should be at least 133'333. The next larger legal value of hashsize is 262'144 which is very wasteful (but fast).
So for such large hashtables we can't really afford to avoid the bucket search. Instead we try to find a balance between the size of a bucket and the number of buckets. If we put 8 entries inside a bucket on average then we get 12'500 buckets. The next legal value for hashsize is 16'384, which gets us 6 entries in average in reality. This should yield acceptable performance vs. small enough space.
back
|
next
maxelem is easy: this limits how many entries the ipset can have.
hashsize however is a tuning parameter. It defines how many hash buckets are allocated for the hashtable. This is the amount of memory that you are willing to sacrifice. It has a very coarse granularity and accepts only values that are equal to 2^n where n is 1..32.
Hashtables are most efficient (buckets mostly contain only a single key, eliminating the search within a bucket) when only 3/4 of their buckets are actually used (1/4 is free). But for large ipsets this is not practical as it would waste a lot of memory. For example for an ipset with 100'000 entries the hashsize should be at least 133'333. The next larger legal value of hashsize is 262'144 which is very wasteful (but fast).
So for such large hashtables we can't really afford to avoid the bucket search. Instead we try to find a balance between the size of a bucket and the number of buckets. If we put 8 entries inside a bucket on average then we get 12'500 buckets. The next legal value for hashsize is 16'384, which gets us 6 entries in average in reality. This should yield acceptable performance vs. small enough space.