it was said:
All,
This post is not about BSD VS. Linux and should not be taken that
way. I think that Flame Wars/Engineer Wars are waste of time and
energy. I was surprised by my test results and didn't want to take
FBSD out of the loop just yet. There may be flaws in my testing that
have led me to inaccurate results. I didn't share the testing details
in the original mail because of time constraints, and the notes are
fairly lengthy. I will add my notes to this mail so that there is a
better understanding of what tests I performed, and their results.
It's important to note that I did not tweak any of the default
settings of the OS or DB. The notes should be generally self
explanatory, but will be more that happy to clarify any questions that
you have. As a side note, I chose the email address linicks because
by name is Nick, and thought it was a fun play on words. I appreciate
all of your feedback, so that I can better understand the differences
in these great operating systems and communities.
Thanks Again!
--Nick Pavlica
Hello,
I'm glad you weren't trolling. I, too, think the OS wars are a load of
cark. Each OS has it strengths and weaknesses. Time is better spent
increasing the strengths and fixing the weaknesses than arguing about
whose are _better_.
I can say right off that FBSD's out-of-the-box state is intended for
stability rather than performance. The real question is what they do
after tuning. Here I would expect FBSD to do somewhat better,
especially on the uni-processor machine. Running the tests on the SC400
hardware won't be a problem for me, but I have no spare SMP or SCSI
equipment to do the PE2400 tests - which I think would be the more
interesting. Perhaps someone else on the list can do this? Not to
provide a head-to-head showdown but to see if something is actually
wrong that isn't already being looked at. (Everyone knows threading has
problems that are being dealt with. That's why I'm not so sure FBSD
will out-perform Fedora at this time on an SMP box.)
To be on the safe side, I'll cc this to the performance list, as well.
Maybe someone has already done something similar and has quick answers.
Thus, I'm including unquoted the rest of your email below.
Finally, the addy thing was just me getting in a shot at you if you had
turned out to be trolling.
Regards,
stheg
The tests and results below here. I don't know how the formatting is
going to turn out. If its too mangled, see the original post on
questions@
OK, The testing notes already :)
---
Hardware Configs:
Dell PE 2400
- Dual PIII 500Mhz
- 512Mb Ram
- Perc 2si controller
- (2) 10k ultra160 drives in a raid 1 configuration.
Dell SC400
- P4 2.4 Ghz (not hyperthreaded)
- 512Mb Ram
- Stock 40Gb IDE 7200RPM
Postgresql Test Scripts:
CREATE TABLE test1 (
thedate TIMESTAMP,
astring VARCHAR(200),
anumber INTEGER
);
CREATE FUNCTION build_data() RETURNS integer AS '
DECLARE
i INTEGER DEFAULT 0;
curtime TIMESTAMP;
BEGIN
FOR i IN 1..100 LOOP
curtime := ''now'';
INSERT INTO test1 VALUES (curtime, ''test string'', i);
END LOOP;
RETURN 1;
END;
' LANGUAGE 'plpgsql';
SELECT build_data();
Then the following script is run under the time program to ascertain
how long it takes to run:
CREATE TABLE test2 (
thedate TIMESTAMP,
astring VARCHAR(200),
anumber INTEGER
);
CREATE TABLE test3 AS SELECT * FROM test1;
INSERT INTO test2 SELECT * FROM test1 WHERE ((anumber % 2) = 0);
DELETE FROM test3 WHERE ((anumber % 2) = 0);
DELETE FROM test3 WHERE ((anumber % 13) = 0);
CREATE TABLE test4 AS
SELECT test1.thedate AS t1date,
test2.thedate AS t2date,
test1.astring AS t1string,
test2.astring AS t2string,
test1.anumber AS t1number,
test2.anumber AS t2number
FROM test1 JOIN test2 ON test1.anumber=test2.anumber;
UPDATE test3 SET thedate='now' WHERE ((anumber % 5) = 0);
DROP TABLE test4;
CREATE TABLE test4 AS SELECT * FROM test1;
DELETE FROM test4 WHERE ((anumber % 27) = 0);
VACUUM ANALYZE;
VACUUM FULL;
DROP TABLE test4;
DROP TABLE test3;
DROP TABLE test2;
VACUUM FULL;
-
sc400 freeBSD5:
$ time dd bs=1024 if=/dev/zero of=tstfile count=1M
1048576+0 records in
1048576+0 records out
1073741824 bytes transferred in 71.807645 secs (14953029 bytes/sec)
71.82real 0.68 user 8.83 sys
71.82 / 60 = 1.197
--
517 nick.pavlica -160 1212K 588K wdrain 0:02 12.35% 5.91% dd
517 nick.pavlica -160 1212K 588K wdrain 0:13 12.48% 12.35% dd
$ time dd bs=1024 if=/dev/zero of=tstfile count=2M
2097152+0 records in
2097152+0 records out
2147483648 bytes transferred in 136.815925 secs (15696153 bytes/sec)
136.85 real 1.29
