select START_TIME, component, oper_type, oper_mode,status, initial_size/1024/1024 "INITIAL", target_size/1024/1024 "TARGET", FINAL_SIZE/1024/1024 "FINAL", END_TIME from v$sga_resize_ops order by start_time, component;

root@narf /etc/init.d # head ssh
#! /bin/sh

### BEGIN INIT INFO
# Provides:             sshd
# Required-Start:       $remote_fs $syslog
# Required-Stop:        $remote_fs $syslog
# Default-Start:        2 3 4 5
# Default-Stop:
# Short-Description:    OpenBSD Secure Shell server
### END INIT INFO

root@narf /etc/rc2.d # ls -l S01*
lrwxrwxrwx 1 root root 20 Oct 25 10:46 S01fancontrol -> ../init.d/fancontrol
lrwxrwxrwx 1 root root 19 Oct 25 10:40 S01mailgraph -> ../init.d/mailgraph
lrwxrwxrwx 1 root root 17 Oct 25 08:58 S01rsyslog -> ../init.d/rsyslog
lrwxrwxrwx 1 root root 19 Oct 25 10:45 S01saslauthd -> ../init.d/saslauthd
lrwxrwxrwx 1 root root 14 Oct 25 10:42 S01sudo -> ../init.d/sudo

root@narf /etc/rc2.d # ls -l *ssh
lrwxrwxrwx 1 root root 13 Oct 25 10:44 S04ssh -> ../init.d/ssh/pre>

root@narf /etc/rc2.d # ls -l S02*
lrwxrwxrwx 1 root root 17 Oct 25 10:41 S02apache2 -> ../init.d/apache2
root@narf /etc/rc2.d # ls -l S03*
lrwxrwxrwx 1 root root 17 Oct 25 10:44 S03openvpn -> ../init.d/openvpn

root@narf /etc/rc2.d # grep -i "INTERACTIVE" *
S02apache2:# X-Interactive:     true
S03openvpn:# X-Interactive:     true

• For Solaris there is for each major update a document updated called “Oracle Solaris Tunable Parameters Reference Manual”. It’s available at here.Check your tuning script at each update against this document in order to ensure that you settings make sense. The 817-0404 is a great read anyway, as it gives you an condensed overview over the possible official knobs to turn.
• Each tuning script has to be carefully designed for each system for each workload. An /etc/system for a database make perhaps no sense for a webserver or may even reduce the performance and vice versa. That’s the reason why I don’t like tuning scripts as part of jumpstart configurations. An NFS server delivering many small files to many clients may need other tunings than a server delivering few large files to a few clients.
• Understand! Understand how components of your architecture interact. Understand the load. Monitor the load for a while. Tuning is at foremost doing a lot of research before and just at last about putting some lines into some scripts. That’s one of the reason why I like tools like dtrace in general, and the scripts from the dtracetoolkit especially. Those tools are like the professionals tools of a mechanic. They can help you to understand the load. The equivalent of the basic set of screwdrivers: All the *stat tools are helpful, too. You need them to know where you can start with the more advanced tools, that are often too focused.
• Have a benchmark load. Have a mechanism to reproduce the load on the system. The more realistic and the less synthetic the better. So you can quantify the impact of each tuning.
• Just change one knob at a time. Otherwise you will never know what setting really helped you or which setting hurted the performance
• Of course: Experience helps a lot in shorten the research phase and sometimes there are some low-brainer settings. But even when you think “Nah … this is just a webserver. Let’s use script number 7b”, you may be surprised by interesting side effects. So there is such think like a no-brainer in tuning
• Large standard applications have often a set of certain tuning parameters that the vendor suggest as a good baseline: At first - look them up in the tuning guide in order if the ISV tuning guide wasn't overtaken by the defaults in the OS. At second: Check them with the vendors manuals with each release ... had once a performance problem with customer that used the tuning parameters suggested for - let's say - version 2, however there weren't that reasonable with version 5.
• It's a good practice to create two baselines: At first check the service performance with a totally untuned system ... just modify settings you need to get the software up-and-running.Run your benchmark. Configure the system with the vendor suggested parameters. Rerun the benchmark. Now do your own tunings. Rerun the benchmark with each knob you turn. And ask yourself: Is the performance impact worth the deviation from the standard parameters from a plain vanilla installation? With such baselines you can assess the impact and thus the value.

$SIG{TERM}=\&signalhandler_TERM; 

sub signalhandler_TERM{ 
     $SIG{TERM} = \&signalhandler_TERM; 
     print "leaving process\n";
     #some code to clean up behind you 
     exit(1); 
}

Always try a normal kill first. There is just one execption.
• The exception: You know that the integrity of data is depending on the fact, that the process has no chance to write anything for example by executing a signal handler. Consider it as something like a forced panic on process level. The panic is the admins friend as it ensures that nothing is written to disk as soon as the OS is detecting something worth to trigger a panic. A panic isn't a "insult the admin"-thing … it's about protecting data.
• kill -9 is your emergency stop switch and shouldn't be part of your normal administrative procedures in any way
• Just sending a -9 after a normal kill without thinking about reasons is bad administrative style.

The X axis shows time and the Y axis shows the approximate percentage of the drive that has been zeroed out. In all three SSD runs, around 160 seconds from the log-in time (i.e. around 200 seconds from power-on), the SSD begins to wipe the drive. After approximately 300 seconds from log-in, the SSD consistently appears to pause briefly before continuing. 350 seconds after log-in, the SSD’s pre-existing evidence data has been almost entirely wiped.

It seems possible that the golden age for forensic recovery and analysis of deleted data and deleted metadata may now be ending.

A new smf service svc:/system/zones-monitoring:default will execute a zones monitoring daemon. This daemon will implement monitoring the system configuration, managing extended accounting, and computing memory utilization on behalf of clients.

# zonestat 5 1
    SUMMARY
                        -----CPU------------- ----PHYSICAL--- ----VIRTUAL----
                   ZONE USED %PART %CAP %SHRU USED  PCT  %CAP  USED  PCT %CAP
                [total] 9.74   30%    -     - 7576M  23%    - 11.6G  24%    -
               [system] 0.28  0.8%    -     - 6535M  19%    - 10.4G  21%    -
                 global 9.10   28%    -     -  272M 0.8%    -  366M 0.7%    -
              kodiak-ab 0.32  1.0%    -     -  256M 0.7%    -  265M 0.5%    -
             kodiak-rie 0.00  0.0%    -     - 22.7M 0.0%    - 49.4M 0.1%    -

# zonestat -p -r memory -q -R average,high 30s 24h 1h