So, first thing I learned is to have the packages foremost and sleuthkit installed. Then I basically followed the steps laid out in the article Why Recovering a Deleted Ext3 File Is Difficult. It worked for me and only leaves me wondering why these steps couldn’t be automated a bit.
Additional links:
- http://foremost.sourceforge.net/foremost.html
- http://www.sleuthkit.org/sleuthkit/
I followed the directions here:
http://outflux.net/blog/archives/2007/04/02/apparmor-now-in-feisty/
These are the requirements for new system purchases. Well, the dual-core actually isn’t but all chips with virtualization extensions are dual core.
- AMD Athlon 64 X2 3600+ Brisbane 1.9GHz Socket AM2 – OEM about $60
- Intel Pentium D 930 Presler 3.0GHz LGA 775 – OEM about $90
- Intel Core 2 Duo E6300 Conroe 1.86GHz LGA 775 – OEM about $165
I was working with the configuration tool puppet the other night and got this error message:
“err: State got corrupted”
Thankfully it wasn’t too big a deal, unlike in the wider world.
I managed to resolve a couple of issues with tuning the debian ip network stack today.
- ip_conntrack_tcp_timeout_established - I have been setting this value to 86400 (1 day in seconds) instead of the default 432000 (5 days in seconds) via sysctl.conf. The problem is that debian loads the sysctl.conf values before the network is loaded (procps.sh runs at 30, networking and shorewall at 40). So for now, not wanting to risk breaking anything that might need that script to run at 30 I just run it again at 41.
- tcp_wmem & tcp_rmem - After doing research on tcp_window_scaling on Debian I ran across a number of people having problems because of the default debian values for these parameters beginning with kernel 2.6.17 and still the default with 2.6.18-4. People recommended the following values (the old debian defaults and current ubuntu defaults):
net.ipv4.tcp_wmem = 4096 16384 131072
net.ipv4.tcp_rmem = 4096 87380 174760
Continue reading Debian ip stack tuning
I was helping a friend with recommendations for an LCD monitor to be used for a computer but also to phase out the television. I found the sweetspot to be the 22″ widescreen LCD for around $300.
Here are the 3 I proposed:
I think du may be the most intolerable command in linux. The info is sometimes so important but it can take hours to get. So in a search for something better I came across enh-du which does seem faster but not by enough.
Managed to catch the commit here. Looks good enough to try on a production system in the not too distant future.
So another day devoted to traffic shaping, particularly as it relates to voip. That means playing with traffic shaping rules, often with a distinct lack of documentation, and then testing to see if they make a difference. So today I learned about HFSC after reading a quote in a discussion about HTB CBQ VOIP and latency, “HFSC may be the best solution, but there aren’t many examples/much support for it yet.” Basically the problem is that CBQ and HTB introduce latency which is very problematic for VOIP. Using the Hierarchical Fair Service Curve Scheduler one can guarantee latencies (as far as leaving the device). So I put it into place and so far it’s looking like a great replacement for HTB. I’ve measured losses in packet drops and jitter. The main downside is that lack of decent documentation. Right now I’d say the setup I’m testing is actually less complex than HTB because it requires fewer parameters. With HTB I was tweaking cburst, r2q, quantum, and more to try and achieve the results I wanted. HFSC works pretty well with just the guaranteed rate, the maximum rate, and the latency you wish to ensure. It doesn’t have a prio parameter so thought has to be given to the latency of various classes. It also doesn’t support anything like burst so while a good choice for a system needing to prioritize voip it may not be ideal for a webserver which does not need to prioritize any time sensitive traffic.
Continue reading The black art of traffic shaping: HFSC is your friend
I know ekiga is pretty well known but I was trying some different problems (after being frustrated with certain aspects of ekiga) and I stumbled on twinkle which I’m liking a lot better. Not only does it work better than ekiga and other free and open source softphones that I’ve tested, it also has security via SRTP and ZRTP built in which is really nice if you don’t want people eavedropping on your voip calls.
So it’s worth reading The performance test of 6 leading frameworks though I found it lacking. The methodology is so far removed from a real world scenario that it’s hard to be swayed by the numbers. The results were that Django comes out first in performance, followed by TurboGears and Ruby on Rails 1.1.6. Besides the lack of a real world scenario I also wonder about caching. I know Rails has no caching by default but I have no idea about the other frameworks. And not only that, Rails by default runs in development mode which is much slower due to the additional debugging information and the checking to see if classes have changed (no class caching). However, it would not surprise me if Django was indeed faster just as python is faster than ruby. And I like Django, the little that I’ve used it. I like the speed, I like python, I like the templating, I like the admin. But here’s why I’m going to stick with rails: database migrations, ferret (lucene port) for searching, larger user base (at the moment), unit testing, nice separation of development vs production environments and tools for moving between them. And certainly these strengths and weaknesses have been noted before. But the other issue that the framefwork comparison raises is that Rails 1.2.1 seems much slower than 1.1.6 which is certainly something to investigate.
Well, it’s true, almost all web servers do not proxy efficiently to a cluster of mongrel servers as was detailed in “Yet another post on how to setup Ruby on Rails to deal with high traffic websites.” I tried, in order, apache 2.2, pound 2.0, nginx 0.4.13 which are the more popular web server frontends for a rails mongrel cluster that are available as debian etch packages. All of them fell victim to the behavior documents by Paul Butcher in “Why Rails + mongrel_cluster + load balancing doesn’t work for us and the beginning of a solution.” I even replicated his test procedure for good measure.
I did, however, find one solution that excelled in handling the proxy requests and that is the proxy solution pen (0.15.0, plus pen-service taken from “Pound vs. Pen“). Pen can correctly be configured to only send 1 request to each mongrel instance and queue the rest, sending them to each mongrel instance as they become free. In the highly articial testing I used I saw performance improvements of 3x more requests handled by pen than by the other web server proxy solutions.
The downside is that pen only does proxying. The other reason to use a webserver frontend to a rails web application is to have it server static content like images, stylesheets, javascript, static html, etc so that the mongrel instances can be free to handle dynamic content. So until a webserver with appropriate proxying comes along that means a rails setup might look like this:
webserver (apache, lighttpd, nginx) <-> pen <-> mongrel
Obviously having to proxy twice is not ideal but it is probably the fastest solution until one of the webservers can do proxying properly for rails.
Not that I have a high traffic ruby on rails site yet but the time will come and I want to try and set it up well from the start. The main problem is that ruby on rails is not thread-safe so each request must be handled by a separate process. So generally that means a backend which is conventionally (if that term can be used for discussion on techniques used in the last few months) fastcgi or mongrel/mongrel_cluster. The front end is then generally a load balancer between these. Sometimes there is even a 3rd software component in there somewhere. So the approach that has become popular that I was thinking of using was apache 2.2 with mod_proxy_balancer and mongrel_cluster. However I came across a really significant problem while reading up on this today.
Continue reading Yet another post on how to setup Ruby on Rails to deal with high traffic websites
I started playing with PowerDNS a couple of months back. It wasn’t trivial to install but it wasn’t difficult either. As I find myself needing to move forward on DNS I did some more reading and now I feel that PowerDNS is overkill and I’m leaning toward MaraDNS. MaraDNS seems to fit our ideals, being designed for security and speed. It’s configuration file based which I think is all we need. PowerDNS can use a db backend and replication but I think that’s overkill for our needs at this time. I found some good descriptions of using MaraDNS in 2 parts (part 1, part 2) and a good write-up on the basics of DNS which also recommends the use of the DNSreport.com site.
AnandTech has a great review of the state of video cards for the holiday season but what most interested me was his page on Ultra Budget GPUs. His conclusions were much the same as mine. At the cheapest end try to get a X1300 which should cost just over $50 (less than that I’m not convinced it’s not better to go with an integrated solution). If you can spend more look to a 7300GT the cheapest models of which can be had for around $75. The most interesting cards for me are the fanless, 128-bit, 256MB 7300GT cards from Biostar, Asus, and Gigabyte which range from $85-$95. If those prices should drop $10-$15 after the holidays odds are I’ll get one of those cards for my new home desktop system. I found that this newegg search was helpful for my needs.
So I upgraded a server to 2.6.18 as it had recently entered debian etch. There are some things I already like but one thing that I was hoping to gain, NCQ on the RAID-1 SATA drives, was not to be. Apparently this is because the sata_nv driver does not support NCQ nor is it expected to anytime soon because nvidia wishes to keep their proprietary sata controller secret. So in the logs I recevied “NCQ (depth 0/32)” which is what indicates that the drives support NCQ but the chipset driver does not. I found this handy list of sata driver status and found that there were very few production drivers with NCQ support (ahci, sata_sil24, both open designs). The upside is that ahci, which seems to be an open standard developed by intel, is being embraced by nvidia, ati, via, sis, uli in their current and future designs. I’ll probably do research into which chipsets support ahci in the future. I think for this server I may replace it with a newer cpu/mb/ram with either an intel conroe or amd brisbane cpu and a motherboard chipset with ahci support.
Update: Which chipsets support AHCI?
On the Intel side a techreport review lists the Intel ICH7R and ICH8R as the only chipsets with ahci support and that none of the nVidia chipsets (5xx and 6xx series) do so. Though other reports have listed the 570 as having ahci. Intel’s ICH8, ICH7, ICH6, ICH5, ICH5R all do not support AHCI but the ICH7DH does according to Intel relayed on the linux-ide mailing list (which also links to a blog post about getting NCQ to work in linux).
The ATI SB600 supports AHCI.
Update 2: Intel has a list of chipsets with ahci support.
Postgresql 8.2 was released recently and a lot of people have been singing its praises for performance and robusteness. However the one thing that leaves me choosing mysql is the integrated replication. However I note that debian now has packages for slony and postgres 8.1 in etch (and perhaps 8.2 will make it in before etch is released). So I think it might be worth trying despite that slony, to my understanding, does not replicate schema changes which can complicate replication in a developing webapp (or perhaps even in production). I found a couple of relatively recent comparisons here and here.
On a whim I decided to see how much it would cost to get a dirt-cheap 64-bit system. I have a need for some web servers that do not need to be blazing fast and so will probably be made from parts purchased on ebay. But the temptation to have the cheapest, slowest 64-bit processor is worth investigating.
AMD
Intel
Both of these setups take DDR-400 ram which you can get a stick of 512MB for $45 right now.
Mostly my desktop upgrade from dapper to edgy went well, though there were a few hiccups along the way. The most serious problem was that neither silky nor gaim’s silc plugin were working after the upgrade. So I finally got an account on the ubuntu forums and wrote Silc support in Ubuntu: From Bad to Worse. There was no response and no help so today I posted a followup to that thread on how to get silc support working by compiling gaim from source and a thought on how the package could be fixed in the future.