Have you considered switching to embedded Linux instead of XP? This has the potential to help increase performance, as embedded Linux will most likely have a smaller footprint. Give this a read: http://www.lynuxworks.com/products/whitepapers/xp-vs-linux.php3 Of course, if you're using an application which is completely reliant on Windows, this may not be cost feasible. But, if you application is Java based, as many embedded applications are, the transition from XP to Linux could be pretty simple. Ken On Thu, Jan 13, 2011 at 11:31 AM, Christian Walter <embedded.solutions.at@xxxxxxxxx> wrote: >> ________________________________ >> Von: pgsql-general-owner@xxxxxxxxxxxxxx im Auftrag von Ivan Voras >> Gesendet: Do 13.01.2011 15:47 >> An: pgsql-general@xxxxxxxxxxxxxx >> Betreff: Re: Optimal settings for embedded system running >> PostgreSQL >> >> On 13/01/2011 14:30, Christian Walter wrote: >>> >>> Dear Members, >>> >>> We are currently using PostgreSQL 7.3 on an Embedded System (Based on >>> http://www.msc-ge.com/de/produkte/com/qseven/q7-us15w.html) running >>> Windows XP Embedded / SP3. The onbard flash shows the following >>> performance figures: > > This was a typo. Of course we are using PostgreSQL 8.3 and not 7.3. > >>> >>> - Average read = 15,6Mb/s >>> - 4Kbyte reads = 3,5Mb/s >>> - 1Kbyte read = 1Mb/s >> >> This is very slow. Have you considered something more light-weight like >> SQLite? > > This is comparable to a standard USB2.0 flash drive. Reads are faster > on very large block sizes but I thought postgres by default uses > 8Kbyte. At 8KByte we have about 5000kbyte/s. For example if you > compare a standard flash disk, e.g. > http://www.innodisk.com/production.jsp?flashid=34 so can see that they > specify 26mb/sec as a max. The same is specified here but I think is > is only for very large block sizes. Using a different database is not > an option for us since our software depends on PostgreSQL and on its > JDBC drivers. We are working with the vendor to find a solution for > this but of course this is only a long term option. > >>> We are sometimes facing problems that the system seems to hang due to >>> database activity and now we are looking to improve the situation. If >>> the database application is running and we run the benchmark again >>> figures drop down to zero so we assume that the database (and >>> application) is responsible for the high load. Since the embedded flash >>> is quite hard to change we are looking for solution on improving this. >>> For me it seems that blocksize seems a big issue and I would like to >>> know if a recompile of Postgres with a larger block size would resolve >>> this? >> >> You can, see --with-blocksize and --with-wal-blocksize arguments to >> ./configure, but flash memory is notorious for having really large block >> sizes, on the order of 256 KiB - I suspect it would be very inefficient >> if the database tried to do everything in such large blocks. > > I think increasing to 32Kbyte would not be a problem because 8KByte is > the default. If this can give us some benefit I am willing to give it > a try and recompile the software using VS2005. > >> >>> Are there any other options which should be set for flash based disks >>> since latency is a lower than on harddisks. >> >> First, you need to confirm or find where the real problem is. Windows is >> hard for debugging but you may get some information from the "perfmon" >> applet. > > We have already planned to use perfmon for this task to double check > if its really IO related. I am sure for about 60% because a parallel > harddisk bench shows a decrease in performance when this happens. > >> >> >> >> -- >> Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) >> To make changes to your subscription: >> http://www.postgresql.org/mailpref/pgsql-general >> >> >> >> "YES WE SCAN !" >> >> --------------------------------------------------------------------- >> >> NEW ! > pH-independent Chlorine Sensor < >> >> --------------------------------------------------------------------- >> >> The chlori::lyser is a revolutionary pH- and flow- independent sensor for >> monitoring free chlorine or total chlorine. The digital sensor runs on >> RS485-Modbus, comes works-calibrated, and allows simple "plug & measure" >> functionality on all s::can terminals, panels, and software. It's internal >> buffer electrolyte allows pH-independent measurement between pH 4 to 10+, >> and it's 3 electrode system provides extremely stable readings, even at high >> fluctuations of pH, temperature and flow - with only a minimal requirement >> for maintenance. >> >> plug&measure installation on an s::can panel is recommended. Combine it with >> our pH, conductivity in just one flow-cell and on one panel, or combine with >> one of our turbidity or spectral sensors on an extra panel, >> >> and you will own the most cost efficient, compact and reliable solution for >> your water monitoring purpose available today, at practically zero running >> costs. >> >> >> >> For more information please visit our website http://www.s-can.at or call >> your local dealer. >> >> >> >> --------------------------------------------------------------------- >> >> s::can - intelligent, optical, online >> >> >> >> scan Messtechnik GmbH >> >> Brigittagasse 22-24 >> >> A-1200 Wien/Vienna >> >> tel. +43 1 219 73 93 - 0 >> >> fax +43 1 219 73 93 - 12 >> >> http://www.s-can.at/ >> >> >> >> SALES@xxxxxxxx Verkauf / Sales >> >> ACCOUNTING@xxxxxxxx Rechnungen / Invoicing >> >> OFFICE@xxxxxxxx Administration / Office >> >> MARKETING@xxxxxxxx Marketing >> >> SUPPORT@xxxxxxxx Technische Unterstuetzung / Technical Support >> >> SERVICE@xxxxxxxx Reparaturen / Repairs >> >> PROCUREMENT@xxxxxxxx Einkauf / Procurement >> >> JOBS@xxxxxxxx Bewerbungen / Jobs >> >> LEGAL@xxxxxxxx Rechtsfragen / Legal questions >> >> >> >> Geschaeftsfuehrer/President: DI Andreas Weingartner >> >> Firmenbuchnummer/Incorporation No: FN178880i >> >> Gerichtsstand/Court of Jurisdiction: Wien/Vienna >> >> >> >> --------------------------------------------------------------------- >> >> Haftungserklaerung / Disclaimer >> >> Der Inhalt dieses E-Mails ist rein informativ und spiegelt nicht >> notwendigerweise den Standpunkt der Firma s::can Messtechnik GmbH wieder. >> >> Sollten Sie eine verbindliche Auskunft benoetigen, wenden Sie sich bitte an >> LEGAL@xxxxxxxxx >> >> This electronic message does not necessarily reflect the official point of >> view of s::can Messtechnik GmbH and is considered as informal information. >> >> To receive a formally binding answer we invite you to contact >> LEGAL@xxxxxxxxx >> >> --------------------------------------------------------------------- >> > > > > -- > -- > +--------------------------------------+-----------------------------------+ > Embedded Solutions | DI Christian Walter > Lorenz Böhler Gasse 4/4, A-1200 Wien | cwalter@xxxxxxxxxxxxxxxxxxxxx > http://www.embedded-solutions.at | +43-664-2486048 > > -- > Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) > To make changes to your subscription: > http://www.postgresql.org/mailpref/pgsql-general > -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
