[ic] How to determine cause of load spikes.

[Kevin Walsh]

DB <DB at m-and-d.com> wrote:
> > I imagine, from the memory usage, that the cause might be an inefficiently
> > crafted Interchange search/scan operation.  The search/scan might be
> > forcing all, or a large chunk, of your products table into memory.  Check
> > the indexes on your table(s), check the search/scan itself and consider
> > using SQL for the search - if you're not already doing so.
> >
> Hi - I suspect that you're correct, but my problem is locating which
> page(s) that these poorly-crafted searches are coming from. I have
> enabled the slow search log and hopefully that will provide clues.
> 
> In the mean time I've realized that indexing more fields of my products
> table may help alot. My 'description' field is type TEXT however - can
> TEXT columns be indexed?
> 
Not in the same way as your other columns, no.  You might want to consider
using the Swish-e search engine.  I use that on my RTFM website, and the
full-text searches on that website are reasonably quick.

Interchange-based search/scan operations will read in a large chunk of
your searched tables and then decide what to throw out, leaving you with
the results you asked for.  That method is fine in most cases, but is
not so good if you have lots of rows and/or have lots of data in the
searched columns.

Building a Swish-e index daily (or on demand) and searching on that,
could be the fix you need - depending upon the searches you perform,
of course.

-- 
   _/   _/  _/_/_/_/  _/    _/  _/_/_/  _/    _/
  _/_/_/   _/_/      _/    _/    _/    _/_/  _/   K e v i n   W a l s h
 _/ _/    _/          _/ _/     _/    _/  _/_/    kevin at cursor.biz
_/   _/  _/_/_/_/      _/    _/_/_/  _/    _/