>>> On 2/22/2012 at 11:22 PM, Ron Foster at Baldor-IS
>>> wrote:
> Hello listers,
> We are experiencing a problem where occasionally we get some uninterruptable
> processes that appear to hang.
> We use CPUPLUGD.
>
-snip-
> I found this hit that might be related:
>
> http://git390.marist.edu/
Hello listers,
We are experiencing a problem where occasionally we get some uninterruptable
processes that appear to hang.
We use CPUPLUGD.
The problem re-appeared whenever we moved workload around and caused some
stress on memory.
I found this hit that might be related:
http://git390.marist.ed
On Wed, Feb 22, 2012 at 11:31 PM, Damian Gallagher
wrote:
> Well, it's important to understand what we mean by " long idle periods on the
> database engine " - in the case of Oracle, the majority of the user work is
> done by the user process, rather than a centralised engine, and that user
>
On our systems, one can get a decent idea of where one is more than half the
time:
If (bogomips ~= 14037)
Processor = z196 && OS = SLES 11
Elif (bogomips ~= 11061)
Processor = z10 && OS = SLES 11 or RHEL 6
Elif (bogomips ~= 2800)
Processor = z196 && OS = SLES 10
Elif (b
Well, it's important to understand what we mean by " long idle periods on the
database engine " - in the case of Oracle, the majority of the user work is
done by the user process, rather than a centralised engine, and that user
process is typically only active 1-5% of the time in an OLTP system
On Wednesday, 02/22/2012 at 05:09 EST, Bernd Oppolzer
wrote:
> See my other post. I'm no "Intel Person".
> I don't believe that all I/O is bad I/O.
> Maybe I don't know enough about today's z/VM.
I recognized you as a z person, Bernd. :-) My "Intel Person" comments
weren't about you, but about
See my other post. I'm no "Intel Person".
I don't believe that all I/O is bad I/O.
Maybe I don't know enough about today's z/VM.
Anyway: I still believe my statements regarding DB systems are valid;
maybe it's no big problem today any more, given the large real memories
of today's machines. But I
Of course.
I would like to add, that I know very well, that the virtualization z/VM
provides
is superior to all other kinds of virtualization, and that there is,
IMO, no problem
with using ORACLE (or DB2 or SQL/DS - who remembers?) on that platform,
because the paging activity on the DB engine si
The whole balance is different on a z. There often just doing the I/O
(especially when you can do lots of them at the *same* time, thus overlapping
them in time) is faster than rummaging around in bufferspace. My experience in
the past has been that on z database engines need an order of magnitu
I don't think that the situation you describe (long idle periods on the
database
engine) is a realistic one. Of course, if such situations happen, the
database
engine's pages have to be paged out by the paging subsystem.
But I had another situation in mind: normal continuous operation of the
data
On Wednesday, 02/22/2012 at 01:18 EST, Bernd Oppolzer
wrote:
> So, of course, the performance of a DB system on a virtual system
> will suffer - if you don't have features like V=R pages (on z/VM, for
> example), where you can fix the real pages of the DB machine.
The z900/z800 was the last machi
> What was BOGOMIPS ever used for?
> I could see, back on slower Intel processors (486), you might need it to
> calculate the amount of times you have to spin a processor to product a delay
> of xx milliseconds.
In rare cases. Mostly it's a bragging item (mine is faster than yours).
On Wed, Feb 22, 2012 at 7:09 PM, Bernd Oppolzer
wrote:
> The database engine or process uses large memory buffers to
> cache the (least recently used) database pages in REAL memory,
> and database performance may degrade significantly, if there is
> paging acitivity on the memory buffers of the d
In back of my mind, I keep on thinking:
Both UNIX (BSD) and LSD came out of University of California, Berkeley.
Coincidence?
Perhaps the person that came up with BOGOMIPS was having a bad trip?
Tom Duerbusch
THD Consulting
>>> Michael MacIsaac 2/22/2012 12:23 PM >>>
> What was BOGOMIPS ever us
> What was BOGOMIPS ever used for?
Recurrent discussions about their uselessness? :))
"Mike MacIsaac"(845) 433-7061
--
For LINUX-390 subscribe / signoff / archive access instructions,
send email to lists...@vm.marist.edu with
I'm no special friend of Oracle, but anyway:
IMHO this is not a political statement.
The database engine or process uses large memory buffers to
cache the (least recently used) database pages in REAL memory,
and database performance may degrade significantly, if there is
paging acitivity on the
Leads to another tangent
What was BOGOMIPS ever used for?
I could see, back on slower Intel processors (486), you might need it to
calculate the amount of times you have to spin a processor to product a delay
of xx milliseconds.
Is there any, near modern, software that uses it now? Whether
Touche'!
Richard and Vickie Pinion
--- damian.gallag...@oracle.com wrote:
From: Damian Gallagher
To: LINUX-390@VM.MARIST.EDU
Subject: Re: Oracle in virtual environments
Date: Wed, 22 Feb 2012 08:13:16 -0800
Thanks Mike and Malcolm for the assist.
I am from Oracle, and I can
Thanks Mike and Malcolm for the assist.
I am from Oracle, and I can quite categorically state that as far as zSeries
and z/VM is concerned, that statement is utter rubbish :-) Our certification
site and the compatibility matrices fully and officially declare that it's all
good. Here's the RAC o
The official virtualiztion matrix is on the Oracle site here:
http://www.oracle.com/technetwork/database/enterprise-edition/db-virtualization-support-133757.pdfhttp://www.oracle.com/technetwork/database/enterprise-edition/db-virtualization-support-133757.pdf
Page 6.
zVM is there, VMWare is not...
If you take into account that MIPS is currently defined as "meaningless
indication of processor speed", and BOGO is derived from bogus, you end up
with a bogus and meaningless indication of processor speed...
Even measuring memory bandwidth is a bogus number on a mainframe, as it
depends heavily on
Harder, Pieter writes:
> Yes, this policy of non-support of Oracle on virtual systems
> applies to VMware as well. That is why we still run our main Oracle
> on Sparc iron. Political trouble ahead ;-)
Berry van Sleeuwen writes:
> In a discussion with our Oracle group they claim that there is n
Hi Berry,
Yes, this policy of non-support of Oracle on virtual systems applies to VMware
as well. That is why we still run our main Oracle on Sparc iron. Political
trouble ahead ;-)
Best regards,
Pieter Harder
pieter.har...@brabantwater.nl
tel +31-73-6837133 / +31-6-47272537
-Oorspro
Hi All,
In a discussion with our Oracle group they claim that there is no support for
Oracle in virtual systems and that they therefore will not support on virtual
systems too. So when a (performance) problem is found they first advise to
migrate to a dedicated server, and increase resources, b
24 matches
Mail list logo
