Weblogs for sneex

Posted by sneex on Mon 9 Jun 2008 at 17:54
Tags: none.
Request for comments -

I wrote the below to somewhat ease the creation of making self-signed certificates -- but while the script executes without error Apache2 (since the SSL update) will not start. I get this error:


[Mon Jun 09 12:17:23 2008] [error] Unable to configure RSA server private key
[Mon Jun 09 12:17:23 2008] [error] SSL Library Error: 185073780 error:0B080074:x509 certificate routines:X509_check_private_key:key values mismatch

This entry has been truncated read the full entry.

 

Posted by sneex on Mon 27 Aug 2007 at 23:27
Tags: none.
[Debian 4 on AMD64 64-Bits]

For the longest time everything under AMD64 appears quiet; until today I noticed a 256T (tera bytes!) /proc/kcore file on one of my servers ... 256T?

I realize that /proc/kcore doesn't truly take any real disk space on the server but I always thought that kcore 'size' was supposed to match 'real memory' size (which should be 8GB on the server in question -- not 256T!)

Thoughts? Comments? Opinions?

 

Posted by sneex on Thu 28 Jun 2007 at 00:49
Tags: ,
My expedition into AMD64: Note 2 ...

OK, so now that I'm done setting up and performance testing the new servers, I need to begin the migration. A little background: I began work here 9 weeks ago, replacing the most recent of about 5 guys who worked here anywhere between 3 weeks to 3 years. All of them have touched the software on the 6 old servers (which these 3 new servers will replace.) A few of the guys who used to work here were programmers of one type or another and I have NO IDEA where all the code is -- very few people left notes. So, after some thinking and digging I remembered another use for the 'locate' command; you know, the one you use in conjunction with updatedb?

Anyways, I know that there are a few hundred PHP, Perl, and related scripts on the old systems, but I have no idea where they all are. So, I wrote the below (modified from a Debian Security Manual shell trick) to, for example, find all the files which have the word 'perl' in them and copy them to a single directory so that I can see what they actually are (note that knowing where they came from at this stage is beside the point.) Once I see which file is what feature I can further refine the search criteria.

for i in { `locate *` }; do [ -f $i ] && { type=`file $i | grep -il perl`; \
[ -n "$type" ] && cp $i ~/Sys.perl.Code; }; done

[ ... the only draw back is that it will copy *all* files which have perl in them, regardless of whether or not they are 'text' scripts or 'gif' binaries... ]

More later...
-Sx-

 

Posted by sneex on Tue 26 Jun 2007 at 14:27
Tags: , ,
BTW - I did spend a couple days trying out the i386 686 BigMem with 32-bit user land as well as the x86_64 install (which is very similar to the overall CentOS 5 64-bit install.)

With disk based activity the x86_64 and pure AMD64 systems faired about the same in overall speed; however with regard to memory and especially network speeds - the pure AMD64 install was about 25 to 33 percent faster. Plus the x86_64 installation 'seemed' to be stuck/glued to a single CPU -- like it didn't want to distribute the load among all the CPUs.

Moving Tar'GZipped files between the systems, packing and unpacking and re-packing them, and sending them back between the systems was a lot better (maybe I'm biased) when using the pure AMD64 installation.

Speaking of speed; the following are what performance parameters I decided upon after a lot of testing (up to terabyte file sizes, etc.)
# 3ware SATA II 9550SX Controller Settings -
# echo cfq > /sys/block/sda/queue/scheduler \
# Set via Kernel option "elevator=xxx" (in /boot/grub/menu.lst)
# These 3 below are set inside /etc/init.d/rc.local
echo 128 > /sys/block/sda/queue/max_sectors_kb
echo 512 > /sys/block/sda/queue/nr_requests
blockdev --setra 16384 /dev/sda

Executing sync; hdparm -t -T /dev/sda1 ; a couple of times yields these results:

/dev/sda1:
Timing cached reads: 1814 MB in 2.00 seconds = 907.13 MB/sec
Timing buffered disk reads: 442 MB in 3.01 seconds = 146.94 MB/sec

/dev/sda1:
Timing cached reads: 1814 MB in 2.00 seconds = 907.08 MB/sec
Timing buffered disk reads: 434 MB in 3.01 seconds = 144.17 MB/sec
... which is about 50% faster that using the Debian defaults, and about 15% faster than 3Ware's recommended 'deadline' scheduler...

Also please see Section 1.

 

Posted by sneex on Tue 26 Jun 2007 at 14:09
Of the three 'identical' AMD64 servers, two say interface eth2 is 100MBits:
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex
eth0: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:47:f9:24
eth1: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:47:f9:25

One states that eth0 is 100MBits:
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex
eth0: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:48:31:f0
eth1: Tigon3 [partno(BCM95704A7) rev 2100 PHY(5704)] (PCIX:100MHz:64-bit) 10/100/1000BaseT Ethernet 00:e0:81:48:31:f1

Question is 'Why?' Why would Debian 4, using the DVD iso installation method, detect the same hardware differently?

So, after further research I see (for srv0) -
dmesg |grep e100
PCI: Firmware left 0000:03:08.0 e100 interrupts enabled, disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfeafb000, irq 201, MAC addr 00:E0:81:48:31:E4
e100: eth0: e100_watchdog: link up, 100Mbps, full-duplex

However for srv1, I see -
dmesg |grep e100
PCI: Firmware left 0000:03:08.0 e100 interrupts enabled, disabling
e100: Intel(R) PRO/100 Network Driver, 3.5.10-k2-NAPI
e100: Copyright(c) 1999-2005 Intel Corporation
e100: eth0: e100_probe: addr 0xfeafb000, irq 177, MAC addr 00:E0:81:47:F9:96
e100: eth2: e100_watchdog: link up, 100Mbps, full-duplex

(NOTE: The 3rd server was hosed while researching why these first two systems do not agree as to the hardware interface; so it's not reported on this AMD64 Section.)

What I am getting at is this: The hardware is the same but the installer doesn't see the same interfaces. In the long run I guess it doesn't matter. I simply want the 1GBit interfaces to plumb-up to my internal/private routes and the 100MBit interfaces to plumb-up to the public/Internet routes. As I have never seen this behavior before it struck me as a little weird.

In summary -

Server 0:
Processors 4
Model Dual Core AMD Opteron(tm) Processor 280
CPU Speed 2.39 GHz
Cache Size 1024 KB
System Bogomips 19120.69
PCI Devices 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
01:03.0 RAID bus controller: 3ware Inc 9550SX SATA-RAID
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
03:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller
03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
03:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
IDE Devices hda: Slimtype DVDRW SSW-8015S
SCSI Devices AMCC 9550SX-4LP DISK (Direct-Access)
USB Devices Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller

Server 1:
Processors 4
Model Dual Core AMD Opteron(tm) Processor 280
CPU Speed 2.39 GHz
Cache Size 1024 KB
System Bogomips 19143.52
PCI Devices 00:07.1 IDE interface: Advanced Micro Devices [AMD] AMD-8111 IDE
00:07.2 SMBus: Advanced Micro Devices [AMD] AMD-8111 SMBus 2.0
00:0a.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
00:0b.1 PIC: Advanced Micro Devices [AMD] AMD-8131 PCI-X IOAPIC
01:03.0 RAID bus controller: 3ware Inc 9550SX SATA-RAID
02:09.0 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
02:09.1 Ethernet controller: Broadcom Corporation NetXtreme BCM5704 Gigabit Ethernet
03:05.0 Mass storage controller: Silicon Image, Inc. SiI 3114 [SATALink/SATARaid] Serial ATA Controller
03:06.0 VGA compatible controller: ATI Technologies Inc Rage XL
03:08.0 Ethernet controller: Intel Corporation 82557/8/9 [Ethernet Pro 100]
IDE Devices hda: Slimtype DVDRW SSW-8015S
SCSI Devices AMCC 9550SX-4LP DISK (Direct-Access)
USB Devices Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller
Linux 2.6.18-4-amd64 ohci_hcd OHCI Host Controller

Looks like the same system, I see the IRQs are different, but would that be enough to cause the 100MHz Ethernet interface show up differently?

 

Posted by sneex on Wed 20 Jun 2007 at 15:58
Tags: ,
My expedition into AMD64 ...

I recently purchased three identical servers with 2 AMD Opteron 280 dual core AMD64 CPUs, 8GB RAM, and 4 500GB SATA II hard drives (setup in a 3 drive RAID 5 with Hot-spare) each.

I spent a few days running CentOS 5 for AMD64 (after trying to create several 80GB files the 3Ware RAID went into a coma (it froze and lost about 160GB of space) -- between trying to get support through CentOS channels (e-mail/IRC) and the 3Ware vendor itself I abandoned CentOS.)

Well, I since own the 3Ware cards now - plus I feel the 9550SX cards are good RAID controllers - I spent the last two weeks running Debian AMD64 ... which is "officially" AMD64 supported now; but ... um, well, let's say it's not exactly ready for me -- at least not for what I wanted to do anyways ... but I am trying.

Mostly documented here will be my experiences -- the good, the bad, and the OMG! of this new adventure.

[ ... more to come ... ]
-Sx-
-----------
NOTE: These articles will more or less be posted in reverse order; I'm not really sure how to get them in chronological order...

 

User Login

Username:

Password:

[ Advanced Login ]

Register Account

Quick Site Search