1) I know DB takes time to load, how will this help me?
2) /dev/zero took on the old machine 11second, on the new machine 6seconds -
doesn't really help as I already knew the new HW is faster on disk - this
through hdparm's speed testing
3) no entropy is access DB is a wrapper around DBI, nothing
Hi Lior,
The file doesn't exist
On Wed, Sep 9, 2009 at 12:34 PM, Lior Okman wrote:
> Noam Rathaus wrote:
>
> They are both running:
>> libc6 2.7-18
>>
>> One (the slower one) also has
>> libc6-i686 2.7-18
>>
>
> Can you check if the file /et
Noam Rathaus wrote:
They are both running:
libc6 2.7-18
One (the slower one) also has
libc6-i686 2.7-18
Can you check if the file /etc/ld.so.nohwcap exists on the slower
machine? If so, remove it and retry.
libc6-i686 had a bug at one po
2009/9/9 Arie Skliarouk :
> Try to run the following on both machines:
>
> #!/usr/bin/perl
> use Time::HiRes;
> ($seconds, $microseconds) = Time::HiRes::gettimeofday;
> print "Start: $seconds.$microseconds\n";
>
> use DB;
>
> ($seconds, $microseconds) = Time::HiRes::gettimeofday;
> print "loaded DB
Try to run the following on both machines:
#!/usr/bin/perl
use Time::HiRes;
($seconds, $microseconds) = Time::HiRes::gettimeofday;
print "Start: $seconds.$microseconds\n";
use DB;
($seconds, $microseconds) = Time::HiRes::gettimeofday;
print "loaded DB: $seconds.$microseconds\n";
Besides "use D
Hi,
I tried them both (the profilers), they just tell me which modules take a
lot of time load, not what the reason are, these modules are quite big, 1000
lines... which makes it harder to just start cutting through to understand
why simply doing:
"use MyModule"
Takes 0.5second to go through
The
They are both running:
libc6 2.7-18
One (the slower one) also has
libc6-i686 2.7-18
(The machines are Debian based)
On Wed, Sep 9, 2009 at 10:18 AM, Tzafrir Cohen wrote:
> On Tue, Sep 08, 2009 at 05:06:26PM +0300, Noam Rathaus wrote:
> > Hi G
On Tue, Sep 08, 2009 at 05:06:26PM +0300, Noam Rathaus wrote:
> Hi Gabor,
>
> I didn't check the network traffic, or name resolving, though both are quite
> fast
>
> Both are running v5.10.0 i486-linux-gnu-thread-multi
What about glibc? Do you have libc6-i686 on the new one as well?
--
Tzafrir
2009/9/8 Noam Rathaus
> Hi,
>
> I have two machines, their hardware is not identical, but their
> installation is.
>
> One is a 3 years old DELL server, while the other is a 1 year old server.
>
> One is running 2.6.26-2-686 while the other 2.6.30-1-686
>
Which distribution is this? The kernel v
Thanks Dotan for the insight
2009/9/8 Dotan Shavit
> On Tuesday 08 September 2009, Noam Rathaus wrote:
> > So I am stuck
> >
> > Grrr
> >
> > Anyone with ideas on how I can understand why "my packages" are causing
> > issues, while apparently, "perl-provided" packages such as LWP::UserAgent
> >
On Tuesday 08 September 2009, Noam Rathaus wrote:
> So I am stuck
>
> Grrr
>
> Anyone with ideas on how I can understand why "my packages" are causing
> issues, while apparently, "perl-provided" packages such as LWP::UserAgent
> dont?
http://www.gksoft.com/a/fun/catch-lion.html
>
> On Tue, Sep 8,
Comparing the two,
I can see that on the slower system
/ <0\.0[^0]
(in VI)
catches 505 read(), brk(), stat64 attempts which take more than 0.01seconds,
1 as high as 0.035575 while 22 taking between 0.019 and 0.30, and the rest
481 above 0.01 and under 0.02
On the other system, there are non tha
Noam Rathaus wrote:
So I am stuck
Did you try "strace -T -f" yet?
Grrr
Anyone with ideas on how I can understand why "my packages" are
causing issues, while apparently, "perl-provided" packages such as
LWP::UserAgent dont?
Did you try an empty "my packages"^H?
Shachar
--
Shachar Shemesh
So I am stuck
Grrr
Anyone with ideas on how I can understand why "my packages" are causing
issues, while apparently, "perl-provided" packages such as LWP::UserAgent
dont?
On Tue, Sep 8, 2009 at 5:58 PM, Shachar Shemesh wrote:
> Noam Rathaus wrote:
>
> The only obvious one is that read() shown
Noam Rathaus wrote:
The only obvious one is that read() shown under strace, takes a
significant more time on the new machine than the old one
You can split the difference between the platforms into three groups:
Time spent in the kernel (0.032 seconds)
Time spent in userspace (7.761 seconds)
Tim
The only obvious one is that read() shown under strace, takes a significant
more time on the new machine than the old one
On Tue, Sep 8, 2009 at 5:43 PM, Shachar Shemesh wrote:
> Noam Meltzer wrote:
>
> the time output does looks like you have higher cpu usage for some reason,
> so i agree with
Hi,
Here you go...
--- old2009-09-08 17:47:41.0 +0300
+++ new2009-09-08 17:47:31.0 +0300
@@ -1,38 +1,45 @@
-tune2fs 1.40-WIP (14-Nov-2006)
-Filesystem volume name: /
+tune2fs 1.41.3 (12-Oct-2008)
+Filesystem volume name:
Last mounted on:
-Filesystem UUID:
Noam Meltzer wrote:
the time output does looks like you have higher cpu usage for some
reason, so i agree with Shachar on this.
you can also try to pinpoint the place the cpu is spent.
strace and/or ltrace with the '-f -c' flags can help.
I'm not sure about ltrace, but strace will not help. Mos
the time output does looks like you have higher cpu usage for some reason,
so i agree with Shachar on this.
you can also try to pinpoint the place the cpu is spent.
strace and/or ltrace with the '-f -c' flags can help.
On Tue, Sep 8, 2009 at 5:24 PM, Shachar Shemesh wrote:
> Noam Rathaus wro
Noam Rathaus wrote:
I know the time difference doesn't look too bad, but take a bigger
code set:
Fast:
real0m1.682s
user0m1.584s
sys0m0.064s
Slow:
real0m16.730s
user0m9.345s
sys0m0.096s
These times spell "CPU intensive". Does your library do anything
special? If you t
Hi,
Interesting riddle...
2009/9/8 Noam Rathaus
> The most notable difference is the read time on files (new HD)
> 0.047210 read(7, " <= 0)\n {\n $numLimit = 10;\n }\n\n "..., 4096)
>
> Instead of (old HW)
> 0.001462 read(6, "owItem = $1;\n\n my $RowItems = $s"..., 4096) = 4096
>
> That is 40
I know the time difference doesn't look too bad, but take a bigger code set:
Fast:
real0m1.682s
user0m1.584s
sys0m0.064s
Slow:
real0m16.730s
user0m9.345s
sys0m0.096s
On Tue, Sep 8, 2009 at 5:15 PM, Noam Rathaus wrote:
> Fast:
>
> time perl t.pl
> Done
> real0m0.431s
Fast:
time perl t.pl
Done
real0m0.431s
user0m0.416s
sys0m0.016s
Slow
time /tmp/t.pl
Done
real0m1.742s
user0m0.864s
sys0m0.008s
On Tue, Sep 8, 2009 at 5:04 PM, Shachar Shemesh wrote:
> Noam Rathaus wrote:
>
> Hi Noam,
>
> 1) Both machines have 2GB of memory and are us
Hi Gabor,
I didn't check the network traffic, or name resolving, though both are quite
fast
Both are running v5.10.0 i486-linux-gnu-thread-multi
They are on different networks
I don't think its a "name" collision, I agree the name DB is not a good
choice :)
tcpdump shows no name resolution occ
Noam Rathaus wrote:
Hi Noam,
1) Both machines have 2GB of memory and are using 200Mb of it..
I think the problem is not memory
So it's probably not IO either.
2) no weird errors, of any kind in the dmesg or /var/log
The newer machine is very new :) I wrote 1 year, it is actually 3
months,
Hi Arie,
It happens every time, not just the first time, so I don't think its seek
time
I am running as root
Both machines are remote, so I can't see thrashing :D
2009/9/8 Arie Skliarouk
> Try to measure disk seek time on both disks:
>
> time echo $(dd if=/dev/sda of=/dev/null count=1 bs=512
Hi,
I would try to focus on the I/O issue. (best guess I have so far)
Some things I would check:
1. file system cache. mayeb the file is already in cache? maybe all memory
is allocated and no free ram for cache? etc.
2. dmesg and/or /var/log/messages -> check if there are weird I/O errors.
(same f
Both machines return around the 0m0.013s value, while the newer one shows a
lower value, not by much (even though it is a 160gb disk, in comparison to
the 40gb disk).
2009/9/8 Arie Skliarouk
> Try to measure disk seek time on both disks:
>
> time echo $(dd if=/dev/sda of=/dev/null count=1 bs=51
Hi Noam,
1) Both machines have 2GB of memory and are using 200Mb of it..
I think the problem is not memory
2) no weird errors, of any kind in the dmesg or /var/log
The newer machine is very new :) I wrote 1 year, it is actually 3 months, I
don't think its a hardware malfunction, but I could be
Try to measure disk seek time on both disks:
time echo $(dd if=/dev/sda of=/dev/null count=1 bs=512; dd if=/dev/sda
of=/dev/null count=1 bs=1 skip=200049647116;)
Replace the last number with size of the disk - several bytes (check using
fdisk -l).
The operation would give meaningful result only
Everything is on the /dev/sda
And local
That is not the answer...
On Tue, Sep 8, 2009 at 3:28 PM, Gabor Szabo wrote:
> 2009/9/8 Noam Rathaus :
> > Hi,
> >
> > I have two machines, their hardware is not identical, but their
> installation
> > is.
> >
> > One is a 3 years old DELL server, while
Hi Noam,
Yes I looked with strace.
The most notable difference is the read time on files (new HD)
0.047210 read(7, " <= 0)\n {\n $numLimit = 10;\n }\n\n "..., 4096)
Instead of (old HW)
0.001462 read(6, "owItem = $1;\n\n my $RowItems = $s"..., 4096) = 4096
That is 40 times slower (it is the sam
2009/9/8 Noam Rathaus :
> Hi,
>
> I have two machines, their hardware is not identical, but their installation
> is.
>
> One is a 3 years old DELL server, while the other is a 1 year old server.
>
> One is running 2.6.26-2-686 while the other 2.6.30-1-686
>
> What I am seeing is slow startup - emph
33 matches
Mail list logo
