Re: [mv] mySQL Database

["Christian J. Müller" <cmueller@polinet.ch>]

******    message to minivend-users from "Christian J. =?iso-8859-1?Q?M=FCller?=" <cmueller@polinet.ch>     ******

"Mr. Christopher F. Miller" wrote:
> 
> ******    message to minivend-users from "Mr. Christopher F. Miller" <cfm@maine.com>     ******
> 
> So your step 1 is to get it more usable just to poke around.  ;^)
> 
> Yes more RAM.  Still, mySQL is rugged.  If you **know** you don't need
> many of those fields, just drop the columns after importing data
> or extract from that table a specialized "products" table with
> just a handful.
> 
> SELECT my,six,or,so,fields FROM big_table INTO my_small_well_indexed_table;

I still cant believe that MV would want to use 413 MB of DRAM simply to
load the mySQL db.

MV is idle and the catalog page is not even showing yet. Why should MV
use that much memory?
This is not a MEMORY database. If the data of my dbs was all in MV, then
I do not need SQL to access a external SQL db.
The mySQ db uses some 230 MB disk space and MV uses 413 MB DRAM!

Chris


> 
> > > > I am playing around with MV4alpha10 on Linux (SuSE 6.3) and a large
> > > > (520,000 recs, 230 MB) mySQL Database. Sartup procedure of the MV server
> > > > takes about 30 mins. Thats long, but I can live with it. However, TOP
> > > > tells me that minivend is using some 420 MB of memory! It eats up all my
> > > > 256 MB DRAM (I thought I was generous when buying 256 MB..) plus most of
> > > > my swap space. Needless to say that the system is very slow.
> > > > I am using a pure mySQL db, which I created in mysql and I have NoImport
> > > > products set. The db has some 90 fields, which I all defined in
> > > > catalog.cfg.
> > > > Does anyone know, whether this is normal. Is my configuration faulty or
> > > > did I miss something?
> > > > It appears as though MV is keeping the whole db in memory!?? That does
> > > > not make sense to me.
> > >
> > > Are you saying you have 90 fields in your products table?  If you access
> > > just a handfull all the time and the rest rarely you might want to
> > > think about splitting it apart.
> >
> > Yes it has 90 fields. The reason being that I am getting this file as is
> > and it is updated dayly/weekly. For reasons of data integrity, I chose
> > to keep all fields, whether or not they are needed.
> >
> > >
> > > Look also at your mySQL logs to see just how that is starting up and the
> > > kinds of queries.  Indexing makes a huge difference in SQL performance.
> > >
> >
> > The mysql log just shows that mv it making a select * query on all
> > tables. Thats all. Nothing unusual.
> > I havn't gotten any further, since the system is so slow, it is unusable
> > unless I add more memory.
> 
> --
> 
> Christopher F. Miller, Publisher                             cfm@maine.com
> MaineStreet Communications, Inc         208 Portland Road, Gray, ME  04039
> 1.207.657.5078                                       http://www.maine.com/
> Database publishing, e-commerce, office/internet integration, Debian linux.
> -
> To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
> email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
> Archive of past messages: http://www.minivend.com/minivend/minivend-list
-
To unsubscribe from the list, DO NOT REPLY to this message.  Instead, send
email with 'UNSUBSCRIBE minivend-users' in the body to Majordomo@minivend.com.
Archive of past messages: http://www.minivend.com/minivend/minivend-list