megaraid cmm: 2.20.2.5 (Release Date: Fri Jan 21 00:01:03 EST 2005) megaraid: 2.20.4.5 (Release Date: Thu Feb 03 12:27:22 EST 2005) megaraid: fw version:[713G] bios version:[G117] scsi0 : LSI Logic MegaRAID driverThis controller does not deliver more than 6MB/s when reading from a mirrored RAID. Sustained write performance is something like 4MB/s, but that's not the worst part: You can write very quickly to it until the on-board cache is full (64MB). While this cache is being flushed the host system comes to a complete halt since every disk access is suspended. The system becomes unusable.
...
gettimeofday({1140077364, 254381}, NULL) = 0
access("./network/admin/sqlnet.ora", F_OK) = -1 ENOENT (No such file or directory)
access("./network/admin/sqlnet.ora", F_OK) = -1 ENOENT (No such file or directory)
fcntl64(169826488, F_SETFD, FD_CLOEXEC) = -1 EBADF (Bad file descriptor)
brk(0) = 0xa20b000
brk(0xa22d000) = 0xa22d000
times(NULL) = -2126335408
times(NULL) = -2126335408
times(NULL) = -2126335408
...
And it keeps calling times() until it is interrupted. Here is a trace
at this time:
(gdb) bt
#0 0x0040d3ed in times () from /lib/tls/libc.so.6
#1 0x01a27599 in sltrgatime64 () from /usr/lib/oracle/10.2.0.1/client/lib/libclntsh.so.10.1
#2 0x0152070f in kghinp () from /usr/lib/oracle/10.2.0.1/client/lib/libclntsh.so.10.1
#3 0x01129b47 in kpuinit0 () from /usr/lib/oracle/10.2.0.1/client/lib/libclntsh.so.10.1
#4 0x01128f8e in kpuinit () from /usr/lib/oracle/10.2.0.1/client/lib/libclntsh.so.10.1
#5 0x011f4c5e in OCIEnvInit () from /usr/lib/oracle/10.2.0.1/client/lib/libclntsh.so.10.1
#6 0x0808d6ea in php_oci_init_globals (oci_globals_p=0x82e7a60) at /root/php-4.4.1/ext/oci8/oci8.c:451
#7 0x0808d765 in zm_startup_oci (type=1, module_number=0) at /root/php-4.4.1/ext/oci8/oci8.c:495
#8 0x08137823 in zend_startup_module (module=0x82c6420) at /root/php-4.4.1/Zend/zend_API.c:1006
#9 0x08111e39 in php_startup_extensions (ptr=0x82e657c, count=-2126330213) at /root/php-4.4.1/main/main.c:1041
#10 0x081471da in php_startup_internal_extensions () at main/internal_functions.c:65
#11 0x08112222 in php_module_startup (sf=0xffffffff, additional_modules=0x0, num_additional_modules=0)
at /root/php-4.4.1/main/main.c:1216
#12 0x0814659d in main (argc=1, argv=0xbfffe654) at /root/php-4.4.1/sapi/cg
The question is: How can such a thing simply break? Is the uptime too
long? What is the Oracle client waiting for? How can I even approach
this proplem? Oh there's no fun anymore (end quote).
<?php
class Slave {
var $master;
function bang() {
$this->master->callback();
}
}
class Master {
var $slave;
var $foo = -1;
function Master() {
$this->foo = 0;
$this->slave = new Slave();
$this->slave->master = & $this;
$this->foo = 1;
echo "1 Master: ".$this->foo."\n";
echo "1 Slave : ".$this->slave->master->foo."\n";
}
function callback() {
echo "Callback from slave: $this->foo (should be 2)\n";
}
function doSomething() {
echo "1_Master: ".$this->foo."\n";
echo "1_Slave : ".$this->slave->master->foo."\n";
$this->foo = 2;
echo "2 Master: ".$this->foo."\n";
echo "2 Slave : ".$this->slave->master->foo."\n";
$this->slave->bang();
}
}
$mst = new Master();
$mst->doSomething();
?>
The copy-on-assign logic of PHP has been a bad idea since it's very
conception, but the ability of assigning references at least made it
possible to work around this "feature" most of the time. 1 Master: 1 1 Slave : 1 1_Master: 1 1_Slave : 1 2 Master: 2 2 Slave : 1 Callback from slave: 1 (should be 2)Which proves that assigning the references works in the constructor but when doSomething() is called, the Master instance and the Slave instance have different copies (?) of the Master. The more I look at it the less i can understand where the copy operation might even take place.