Hello Heikki,
On Wed, 2003-06-04 at 13:26, Heikki Tuuri wrote:
> the memory deallocation seems to happen usually in
>
> "
> if (prebuilt->blob_heap != NULL) {
> mem_heap_free(prebuilt->blob_heap);
> prebuilt->blob_heap = NULL;
> }
> "
>
> select MEET, count(*)
> from RATINGS_WHENU
> where MEET in ('N','Y')
> and SITE = '63'
> group by MEET
>
> You have BLOBs in the table? How big are they? What does SHOW CREATE TABLE
> give as the table definition?
>
mysql> show create table RATINGS_WHENU\G
*************************** 1. row ***************************
Table: RATINGS_WHENU
Create Table: CREATE TABLE `RATINGS_WHENU` (
`ID` int(11) NOT NULL auto_increment,
`SITE` int(11) default NULL,
`CLIENT_ID` varchar(64) default NULL,
`STOCK` char(1) default NULL,
`NAVIGATE` char(1) default NULL,
`TIMELY` char(1) default NULL,
`AGAIN` char(1) default NULL,
`CUSTOMER` char(1) default NULL,
`ENTERED_TIME` datetime default NULL,
`FEEDBACK` text,
`LAST_UPDATE` timestamp(14) NOT NULL,
`MEET` char(1) default NULL,
`CONTACTED` char(1) default NULL,
`COMPLETE` char(1) default NULL,
`SELECTION` char(1) default NULL,
`PRICING` char(1) default NULL,
PRIMARY KEY (`ID`)
) TYPE=InnoDB
1 row in set (0.02 sec)
No blobs.
> What is really strange in the assertion failures on line 372 is that the hex
> dump does show the memory block IS marked free:
>
> "
> InnoDB: Error: Removing element from mem pool free list 7 though the
> InnoDB: element is not marked free! Dump of 100 bytes around element:
> len 100; hex
> 544a5468652073697465206973206a75737420544f4f20534c4f572e204f7468657277697365
> 2c2077656c6c20646f6e652e81000000000000000000000020646566696e6974656c79206265
> 7474657220636f6d707574657220626f6f6b2073656c6563; asc TJThe site is just TOO
> SLOW. Otherwise, well done............. definitely better computer book
> selec;
> 030604 10:22:21 InnoDB: Assertion failure in thread 991475 in file
> mem0pool.c line 372
> "
>
> Memory operations are protected by a mutex. As if the mutex would leak and
> let other threads change the bit meanwhile.
>
Agreed odd.
> > Regarding mem usage, the machine has 1gb, mysql is using 374MB which is
> > fine as far as I am concerned. I can decrease the numbers tho, but the
> > last time I did decrease the numbers you mentioned performance dropped
> > and our batch jobs (not the web queries) now take about 20% longer to
> > run. Do you think decreasing sort and record buffer figures might
> > effect performance?
>
> Best to test it. Note that if there is a spike of load then GROUP BY queries
> can pile up and reserve lots of memory. The question is what is the memory
> usage at the time of a crash.
>
>From monitoring it, we see little change from that 374 megs figure. I
can try and install something that will monitor more than once per
minute (our current granularity).
I will change the buffer sizes as you mention and test.
But, after all of this, where does it lead us? The thing is still
crashing. :(
Best,
Richard
> > Thanks,
> >
> > Richard
>
> Best regards,
>
> Heikki Tuuri
> Innobase Oy
--
Richard F. Rebel
[EMAIL PROTECTED]
t. 212.239.0000
--
MySQL General Mailing List
For list archives: http://lists.mysql.com/mysql
To unsubscribe: http://lists.mysql.com/[EMAIL PROTECTED]
