User Tools
tech:unix:start
Differences
This shows you the differences between two versions of the page.
| Both sides previous revision Previous revision Next revision | Previous revision | ||
|
tech:unix:start [2018/01/23 01:08] rk4n3 |
tech:unix:start [2018/11/25 16:11] (current) rk4n3 |
||
|---|---|---|---|
| Line 1: | Line 1: | ||
| - | Technical UNIX Topics | + | <typo fs:xx-large; fw:bold>UNIX Topics</typo> |
| + | [[tech:unix:solaris:start|Solaris topics]] | ||
| + | |||
| + | ====== Troubleshooting Topics ====== | ||
| + | ===== Troubleshooting SSH ===== | ||
| + | Start an SSH daemon in debug mode:<code>/usr/sbin/sshd -d -p 2222</code> | ||
| + | Connect with client in verbose mode:<code>ssh -vv -p 2222 ServerIP</code> | ||
| + | |||
| + | ------ | ||
| + | ====== AIX Topics ====== | ||
| + | |||
| + | ==== AIX Kernel Lock Table - Front-Loading Overhead ==== | ||
| + | If fcntl is used to aquire locks on files without utilization of the range/region parameters, file locks are aquired without an offset, which has the side-effect of the lock entry being inserted at the beginning of the kernel's lock table. | ||
| + | |||
| + | Interestingly, if an application relies on intensive utilization of such file locking, the overhead of unconditional traversal of the potentially over-sized set of lock entries crowded into the front of the lock table can be quite impactful. | ||
| + | |||
| + | In one particular application, file locks acquired via fcntl was used for IPC-oriented synchronization in addition to actual concurrent file access, which introduced the overhead from kernel lock table front-loading to the application's multi-threaded processing concurrency - and the problem was also aggrevated by the addition IPC-oriented lock volume, as well. | ||
| + | |||
| + | One mitigation technique would be to utilize the region/range parameters for fcntl, locking a region at an arbitrarily-high position, which has the side-effect of the lock entry being located away from the front of the lock table. | ||
| + | |||
| + | ------ | ||
| ====== Sample config files ====== | ====== Sample config files ====== | ||
| ==== .kshrc ==== | ==== .kshrc ==== | ||
| Line 117: | Line 137: | ||
| } | } | ||
| </code> | </code> | ||
| - | |||
| - | ====== Troubleshooting Topics ====== | ||
| - | ===== Troubleshooting SSH ===== | ||
| - | Start an SSH daemon in debug mode:<code>/usr/sbin/sshd -d -p 2222</code> | ||
| - | Connect with client in verbose mode:<code>ssh -vv -p 2222 ServerIP</code> | ||
| - | |||
| - | |||
| - | ====== AIX Topics ====== | ||
| - | |||
| - | ==== AIX Kernel Lock Table - Front-Loading Overhead ==== | ||
| - | If fcntl is used to aquire locks on files without utilization of the range/region parameters, file locks are aquired without an offset, which has the side-effect of the lock entry being inserted at the beginning of the kernel's lock table. | ||
| - | |||
| - | Interestingly, if an application relies on intensive utilization of such file locking, the overhead of unconditional traversal of the potentially over-sized set of lock entries crowded into the front of the lock table can be quite impactful. | ||
| - | |||
| - | In one particular application, file locks acquired via fcntl was used for IPC-oriented synchronization in addition to actual concurrent file access, which introduced the overhead from kernel lock table front-loading to the application's multi-threaded processing concurrency - and the problem was also aggrevated by the addition IPC-oriented lock volume, as well. | ||
| - | |||
| - | One mitigation technique would be to utilize the region/range parameters for fcntl, locking a region at an arbitrarily-high position, which has the side-effect of the lock entry being located away from the front of the lock table. | ||
tech/unix/start.1516691285.txt.gz ยท Last modified: 2018/01/23 01:08 by rk4n3
Page Tools
