rtm

6 ms·

1.
by rtm 14y ago
Old server: two Xeon E5450 chips, 3.0 GHz, 8 cores total, 24 GB RAM. New server: one Xeon E5-2690 chip, 2.9 GHz, 8 cores total, 32 GB RAM.
2.
by rtm 14y ago
Test comment.
3.
by rtm 14y ago
xxxxx
4.
by rtm 15y ago
Address spaces based on paging rather than segments. Much clearer context switching code. File system crash recovery via logging.
5.
by rtm 15y ago
Most students take 6.828 along with three or four other courses.
6.
by rtm 15y ago
http://pdos.csail.mit.edu/6.828/2011/schedule.html
7.
by rtm 15y ago
xxx
8.
by rtm 17y ago
Test 2.
9.
by rtm 17y ago
Test 1.
10.
by rtm 17y ago
Testing.
11.
by rtm 17y ago
fork() and exec() work well as separate system calls for the common situation where the child (but not the parent) needs to adjust something before executing the new program. Changing file descriptors to implement > and < in the she
12.
by rtm 17y ago
this is a test. I think you have already honed in on the basics: "You have to actually do it". If it seems like there are too many things to try and they all look appealing, you just need to understand yourself better and self observation w
13.
by rtm 18y ago
64-bit mzscheme uses about 50% more memory than 32-bit mzscheme to hold all of the Hacker News data.
14.
by rtm 18y ago
Old: 2.4 GHz Pentium 4, 4 GB RAM, 32-bit FreeBSD 5.3. New: 3.0 GHz Core whatever, 12 GB RAM, 64-bit FreeBSD 7.1.
15.
by rtm 18y ago
Nonsense.
16.
by rtm 18y ago
foof
17.
by rtm 19y ago
I ran the test with 1,000,000 INSERTs (taking 200 seconds), with the innodb cache size set to only 200,000 bytes. So there's a fair chance it updated the b-trees on disk.
18.
by rtm 19y ago
167 small transactions per second on MySQL 4.1 / InnoDB / FreeBSD / FFS / SCSI, which looks like one per rotation. Presumably the time required to write a block at the end of the write-ahead log. 5000 per second with --innodb_flush_log_at_t
19.
by rtm 19y ago
On MySQL 4.1 / InnoDB / FreeBSD / FFS / SCSI, small inserts run at about 167 transactions per second, i.e. one per rotation. Same setup but --innodb_flush_log_at_trx_commit=0, a million transactions in 200 seconds, or 5000/second. I don't k
20.
by rtm 19y ago
The drives whose documentation I've read say they may not copy the write-cache to the surface during a power failure. I don't know about other drives, or about why. Such a feature would anyway be hard or impossible to use as part of a desig
21.
by rtm 19y ago
You can configure a drive to delay writing to the disk surface, and instead just write into its cache, until some later point when it's convenient to write the surface. But the reason a DB issues a write to the disk is that the DB needs the
22.
by rtm 19y ago
Deferred logging is a huge deal! Appending a record to a log takes one (or a half) of a rotation. A rotation takes about the same amount of time as a disk seek. So a DB that synchronously appends the on-disk log for each transaction will be
23.
by rtm 19y ago
An ordinary DB writes each update to disk twice, once in the log and once in the permanent DB. DBs do defer updating the permanent DB. But they tend to be eager about flushing the log in order to achieve durability. If you read the documen
24.
by rtm 19y ago
A challenge in a pure version of a log-structured database is reclaiming space from the log when data is no longer needed. Sometimes you don't need to, as in Venti ( http://citeseer.ist.psu.edu/531029.html ).
25.
How MySQL Cluster works(vldb.idi.ntnu.no)
8 points by rtm 20y ago|0 comments
26.
How OkCupid prevents break-ins despite buggy code(okws.org)
12 points by rtm 20y ago|2 comments
27.
Tough AI problem -> game -> surfers will solve for free!(espgame.org)
11 points by rtm 20y ago|2 comments
28.
How to Interview a Programmer(artima.com)
12 points by rtm 20y ago|1 comments
29.
Apache Performance Tuning Tips(arctic.org)
7 points by rtm 20y ago|0 comments
30.
by rtm 20y ago
I wonder what this means for practical system design. Do people currently build assumptions about hard drive failure patterns into their systems, in a way that they should change? I suppose independent failure (i.e. copying data to two

More ›