Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> Re:RE: Re[2]: Sun Boxes Crashing

Re:RE: Re[2]: Sun Boxes Crashing

From: Tommy Pham <TPham_at_specialized.com>
Date: Fri, 08 Sep 2000 09:12:32 -0700
Message-Id: <10613.116521@fatcity.com> 





--MIME MULTIPART BOUNDARY=.968429605:+'1



Content-Type: text/plain; charset=US-ASCII
Content-Id: <1021229020-2_at_specialized.com>
Content-Transfer-Encoding: 7bit





Yes,  in Celsius.  My typo.   Sun FE recommended low 30's.   Ours
avg. out to 30 deg. Cel.



TP.






        ,--o         ,--o         ,--o          ,--o
      _-\_<_        _-\_<_       _-\_<_       _-\_<_  let's bike!!! 
     (*)/-'(*) ___ (*)/-'(*) __ (*)/-'(*) __ (*)/-(*)        



____________________Reply Separator____________________


Subject:    RE: Re[2]: Sun Boxes Crashing
Author: ORACLE-L_at_fatcity.com


Date:       9/7/00 5:11 PM



You mean low 30's degrees Celsius right?



One of my CPU boards on an E4500 shows a max temp of 39 degrees C.



Has Sun recommended an acceptable max temp to avoid this problem?



TIA,



Gerardo



-----Original Message-----



Sent: Thursday, September 07, 2000 11:56 AM
To: Multiple recipients of list ORACLE-L




We had the parameters set since day one.   It didn't correct the problem.
One


thing that has helped/kept our system (E6500) up and running by cooling down
our


computer room.   Prtdiag -v shows the memory/cpu boards are in the low 30's
F.  


 We still don't an answer from Sun yet.



TP


Sr. Apps DBA / Solaris Systems Admin.





        ,--o         ,--o         ,--o          ,--o
      _-\_<_        _-\_<_       _-\_<_       _-\_<_  let's bike!!! 
     (*)/-'(*) ___ (*)/-'(*) __ (*)/-'(*) __ (*)/-(*)        



____________________Reply Separator____________________
Author: ORACLE-L_at_fatcity.com
Date:       9/6/00 10:20 PM







Sounds exactly like the type of problem we experienced recently (same
environment)...here is a response direct from Sun techo's:



I've had a look at the crash dump and the problem appears to be
that a kernel thread's stack overflowed.



This, unfortunately, happens occasionally if you run with too many levels
of different filesystems/device layers. (In your case vxfs/vxio/sd)



The only real way to fix/workaround the problem is to increase the size of
the


kernel stacks.



i'd suggest you add



set rpcmod:svc_run_stksize=0x4000


set lwp_default_stksize=0x4000



to /etc/system then reboot the domain to take effect.



the only reason it happened is because the kernel thread was interrupted to
service a disk request. This pushed the stack over the normal 0x2000 limit.



The crash was sufficient to corrupt one of our largest datafiles and
appeared to


occur after running a large insert batch job in parallel.



We only made these changes yesterday afternoon so obviously it's too early
to


qualify!



Regards


Grant







"Rama Malladi" <rmalladi_at_inteliant.com> on 07/09/2000 08:40:38



Please respond to ORACLE-L_at_fatcity.com




To:   Multiple recipients of list ORACLE-L <ORACLE-L_at_fatcity.com>
cc:    (bcc: GRANT G HOLYOAKE/NSO/CSDA)





We have several Sun boxes (Solaris 2.6) running Oracle 8, 8i. One of the
boxes (description given below) Kept rebooting and this machine happens to
run one of the most critical billing systems (Murphy's law!).



Overall, this machine rebooted some 40 times, in a period of 2 months and
some nights, it rebooted as many as 10 times! Our SysAdmin contacted Sun
Engineers and they never told us what exactly was the problem, and kept
replacing CPUs, Memory boards, SCSI cards etc ... This happened several
times and last week there was an article in Computer Weekly magazine saying
several customers were having this kind of problem on Sun boxes and Sun
tried to hush up the matter ...!!



Has anybody else faced this kind of situation?



Just curious ...


Rama





System Configuration:  Sun Microsystems  sun4u 8-slot Sun Enterprise
E4500/E5500


SunOS uscaelmux06 5.6 Generic_105181-21 sun4u sparc SUNW,Ultra-Enterprise



--



Author: Rama Malladi


  INET: rmalladi_at_inteliant.com


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message


to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).








-- 



Author: 


  INET: grant.g.holyoake_at_centrelink.gov.au


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message


to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


 


-- 



Author: Molina, Gerardo


  INET: Gerardo.Molina_at_schwab.com


Fat City Network Services    -- (858) 538-5051  FAX: (858) 538-5051
San Diego, California        -- Public Internet access / Mailing Lists


--------------------------------------------------------------------

To REMOVE yourself from this mailing list, send an E-Mail message


to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from).  You may
also send the HELP command for other information (like subscribing).


 



--MIME MULTIPART BOUNDARY=.968429605:+'1



Content-Type: application/octet-stream
Content-Id: <1021229020-3_at_specialized.com>
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="RFC822.txt"





UmVjZWl2ZWQ6IGZyb20gVW5rbm93biBob3N0IFsyMDguMTk1LjE4Mi40OF0gYnkgc3BlY2lhbGl6
ZWQuY29tIChjY01haWwgTGluayB0byBTTVRQIFI4LjUyLjAyLjEpDQoJOyBUaHUsIDA3IFNlcCAy
MDAwIDE2OjE3OjM2IC0wNzAwDQpSZXR1cm4tUGF0aDogcm9vdEBmYXRjaXR5LmN0cy5jb20NClJl
Y2VpdmVkOiBmcm9tIG5ld3NmZWVkLmN0cy5jb20gKFsyMDkuNjguMTkyLjE5OV0pIGJ5IDIwOC4x
OTUuMTgyLjQ4DQogIChOb3J0b24gQW50aVZpcnVzIGZvciBJbnRlcm5ldCBFbWFpbCBHYXRld2F5
cyAxLjApIDsNCiAgVGh1LCAwNyBTZXAgMjAwMCAyMzoxOToxMyAwMDAwIChHTVQpDQpSZWNlaXZl
ZDogZnJvbSBmYXRjaXR5LlVVQ1AgKHV1Y3BAbG9jYWxob3N0KQ0KCWJ5IG5ld3NmZWVkLmN0cy5j
b20gKDguOS4zLzguOS4zKSB3aXRoIFVVQ1AgaWQgUUFBNDMwNzc7DQoJVGh1LCA3IFNlcCAyMDAw
IDE2OjE2OjQxIC0wNzAwIChQRFQpDQpSZWNlaXZlZDogYnkgZmF0Y2l0eS5jb20gKDA0LU1heS0y
MDAwL3YxLjBmLWI2OS9iYWIpIHZpYSBVVUNQIGlkIDAwMUY2RjlGOyBUaHUsIDA3IFNlcCAyMDAw
IDE2OjExOjA5IC0wODAwDQpNZXNzYWdlLUlEOiA8RjAwMS4wMDFGNkY5Ri4yMDAwMDkwNzE2MTEw
OUBmYXRjaXR5LmNvbT4NCkRhdGU6IFRodSwgMDcgU2VwIDIwMDAgMTY6MTE6MDkgLTA4MDANClRv
OiBNdWx0aXBsZSByZWNpcGllbnRzIG9mIGxpc3QgT1JBQ0xFLUwgPE9SQUNMRS1MQGZhdGNpdHku
Y29tPg0KWC1Db21tZW50OiBPcmFjbGUgUkRCTVMgQ29tbXVuaXR5IEZvcnVtDQpYLVNlbmRlcjog
Ik1vbGluYSwgR2VyYXJkbyIgPEdlcmFyZG8uTW9saW5hQHNjaHdhYi5jb20+DQpTZW5kZXI6IHJv
b3RAZmF0Y2l0eS5jb20NClJlcGx5LVRvOiBPUkFDTEUtTEBmYXRjaXR5LmNvbQ0KRXJyb3JzLVRv
OiBNTC1FUlJPUlNAZmF0Y2l0eS5jb20NCkZyb206ICJNb2xpbmEsIEdlcmFyZG8iIDxHZXJhcmRv
Lk1vbGluYUBzY2h3YWIuY29tPg0KU3ViamVjdDogUkU6IFJlWzJdOiBTdW4gQm94ZXMgQ3Jhc2hp
bmcNCk9yZ2FuaXphdGlvbjogRmF0IENpdHkgTmV0d29yayBTZXJ2aWNlcywgU2FuIERpZWdvLCBD
YWxpZm9ybmlhDQpYLUxpc3RTZXJ2ZXI6IHYxLjBmLCBidWlsZCA2OTsgTGlzdEd1cnUgKGMpIDE5
OTYtMjAwMCBCcnVjZSBBLiBCZXJnbWFuDQpQcmVjZWRlbmNlOiBidWxrDQpNaW1lLVZlcnNpb246
Received on Fri Sep 08 2000 - 11:12:32 CDT












Original text of this message













  HOME |
  ASK QUESTION |
  ADD INFO |
  SEARCH |
  E-MAIL US