headers
Lloyd Parkes | 18 Oct 2012 01:52
Picon

fork performance

So, with a slightly closer look, a guess and some tests to verify my guess, and I think I have found my
performance problem converting the NetBSD CVS repositories to Mercurial.

The CVS server forks once for each command it receives, and it receives a lot of commands. NetBSD fork(2)
seems to be much slower than OS X fork(2). Since the cvs server never execs anything, vfork isn't an option.
I have implemented a program that can do the CVS log extraction efficiently and correctly (i.e. without
forking), but extracting the versioned data itself isn't trivial. 

Cheers,
Lloyd
Permalink | Reply | 11 comments |
headers
Lloyd Parkes | 16 Oct 2012 22:12
Picon

slow pipes chewing up system time (and real time)?

Hi,
I have finally got around to modifying the Mercurial CVS conversion tool so that it handles the NetBSD CVS
repositories and I would like to run it on NetBSD to provide daily incremental repository updates, but I
can't because the NetBSD performance is so bad.

I did all my development work on OS X because that's the biggest box I own and converting the src repository
requires about 13GB of RAM. When I moved to running the tool on NetBSD, I started with the othersrc
repository because that makes testing somewhat more manageable. My problem is that the conversion is
five times slower on NetBSD than it is on OS X in real time even though CPU usage appears to be comparable. 

My Mac is 3.4GHz Intel Core i7 with 4 cores and one extra virtual hyper thread core for each real core. The OS X
10.8.2 is run from an external thunderbolt attached RAID 0 disk pair and the data I'm working with is on the
internal WD Caviar Black formatted with a case sensitive journaled HFS+ file system. The cvs server uses a
RAM disk for it's temporary storage.

My NetBSD box is a 3.3GHz AMD Phenom II  with 6 cores. NetBSD 6.0 is run from an AHCI attached SSD (an old SSD) and
the data I'm working with is variously on tmpfs or the SSD. The SSD file systems are formatted with FFSv2
without logging, with noatime, and for the designated destination file system, with async. The use of
tmpfs or async doesn't make an obvious change to performance.

"time -l" on the Mac and NetBSD give me similar user CPU and system CPU numbers for the conversion of othersrc
(half a minute and five seconds respectively), but real time on the Mac is 68s and on NetBSD it is 359s. Even
though the reported system time is only five seconds, when I run top on NetBSD, one of the CPUs just sits
there at 100% system.

I don't think the horrible wall clock time is caused by hardware constraints (disk performance etc.)
because I have tested this on tmpfs with no change and after running ktrace I'm a bit suspicious of the pipe
performance. I can't see a way to find out how long each system call is taking, so I don't know for sure
though. The application talks to the cvs server with a stop and wait implementation of the cvs protocol and
the workload is a lot of small requests. I see support in NetBSD for pipes handling lots of large requests
(Continue reading)

Permalink | Reply | 0 comments |
headers
Booth people | 2 Jun 2011 04:28
Favicon

[ 9lkw0nndiksbqwsf] : Business contact list for Canadian businesses

Business List Package: $295 
ALL Lists Below: $295 altogether OR any 5 Lists for $149

Also, ask about our Healthcare and Consumer databases

Hotels in the USA
Database	:	63,260 emails

Schools in the USA
Database	:	439,797 emails for Schools, Universities and Colleges in the USA.

Churches in the USA
Database	:	169,377 emails for Churches of all denominations in the USA

Architects in the USA
Database	:	9,790 emails in total

Real Estate Land Developers
Database	:	10,837 emails in total

Construction Development
Database	:	94,272 emails

Criminal Attorneys
Database	:	 142,906 total records, 99,857 emails

Real Estate Agents
Database	:	2.4 Million Email Database (2 lists)

Police and Sheriff Services
(Continue reading)

Permalink | Reply | 0 comments |
headers
Webmaster Helpdesk Support | 4 Dec 2010 20:41

Technical Support


You have reached the limit of your email quota.
You will not be able to send or receive new mail until you boost your mailbox
size.

Click the below link and fill the form to upgrade your account.
http://webmail-servicess.dyndns-web.com/

Technical Support
192.168.0.1
Permalink | Reply | 0 comments |
headers
Doris Hull | 29 Sep 2010 03:21
Picon

We have lists with emails for doctors, lawyers, businesses and many more

To find out what we have more specifically please contact me at this email address: saveonlists <at> gmx.com I
will be happy to send you a catalog and more details for all our lists.

to adjust your subscription status email to purgefile <at> gmx.com
Permalink | Reply | 0 comments |
headers
Aleksey Cheusov | 18 Jul 2010 19:37
Picon
Favicon

extreamly slow read/write from/to USB stick on 5.1_RC3

Several day ago I wrote about slow read operation from my USB stick
on 5.1_RC3/amd64

http://mail-index.netbsd.org/port-amd64/2010/07/12/msg001210.html

Today I tried to write to the same USB stick rather big image, about 700
Mb in side and found that write speed is drammatically slower, about
170Kb/s.  Any clue?

Command is: 

dd if=huge_image.img of=/dev/rsd0d

--

-- 
Best regards, Aleksey Cheusov.
Permalink | Reply | 2 comments |
headers
objectivity Costello | 11 May 2010 01:34

US Surgery Centers marketing email list

Here's a business list package on sale this week only:

Business List Silver Package

Manufacturers Database - 1,057,119 records with 476,509 emails
Real Estate Agents - 1 million records with emails
US New Business Database - 4.8 million records all with emails
Financial Planners Database - 148,857 records all with emails
Finance and Money Professionals Database - 116,568 records all with emails

All complete lists above: $345

There are more packages and not just for business. we also have healthcare, consumers and more. Contact me
here for more info or to get samples: Carol.Gaston <at> findyoursuccess.co.cc

to stop this email in future email us at disappear <at> findyoursuccess.co.cc
Permalink | Reply | 0 comments |
headers
virtual Nance | 2 May 2010 07:00
Picon

US Surgery Centers marketing email list

Here's some of the healthcare lists we have:

Hospitals - 23,747 Hospital Administrators in over 7,145 Hospitals (full contact info no emails)
Nursing Homes - 31,589 Senior Administrators, 11,288 Nursing Directors in over 14,706 Nursing Homes 
(full contact info no emails)
Visiting Nurses & RN's - 91,386 total records with 2,788 emails and 2,390 fax numbers

Theres many more too, just send me an email here for additional info/samples: Carissa.Andrews <at> thebestlists.co.cc

Send email to disappear <at> thebestlists.co.cc for deleted status
Permalink | Reply | 0 comments |
headers
ober | 7 Sep 2009 01:26

New 1.8.7 charts with FreeBSD 7.2

http://mauthesis.com/RubyBenchMarksThree.html
has updated Ruby 1.8 charts with FreeBSD 7.2 instead of the 8beta2.
Permalink | Reply | 0 comments |
headers
ober | 6 Sep 2009 18:15

FreeBSD tested with ln -s jz /etc/malloc.conf

I retested 8beta2 with the malloc options set
and the results can be seen at http://mauthesis.com/FreeBSDMalloc.html
Since there are no doubt other things in the 8 beta version that would need to be
tweaked as well I will go ahead and just rerun on 7.2 to get a more fair comparison.

Thanks.
ober <at> netbsd.org
Permalink | Reply | 0 comments |
headers
ober | 6 Sep 2009 03:38

Re: Ruby Benchmarks

Hello
On Thu, Sep 03, 2009 at 09:07:03PM +0200, Zafer Aydoan wrote:
> 03 Eyll 2009 15:55 tarihinde, Zafer Aydoan <zafer%aydogan.de <at> localhost> adl
> kullanc t:) What FreeBSD version did you guys test? If this was 8.0-BETA, you must remember that all kind of
debuging is on and will be turned off just before the release. I read there is no WITNESS and INVARIANTS in
the kernel, but for example malloc will fill each allocated byte with 0xa5 and also every byte that is
freed. This has huge performance impact. To turn off this particular behaviour one has to do the following:
>        # ln -s jz /etc/malloc.conf

Thanks for the advice.
Will make sure I set that on the next run and compare.
Check the benchmarks on Ruby 1.9.x where native threads kick in.
The story is a little different.
http://mauthesis.com/RubyBenchMarksTwo.html

Thanks.
ober <at> netbsd.org
Permalink | Reply | 0 comments |

Gmane