[Building Sakai] Mysql high load Hibernate
John Bush
john.bush at rsmart.com
Mon Feb 28 13:33:48 PST 2011
Oops, I misreported this, actually these problems were from 2.6.x
implementations, so that is consistent with what you are saying.
On Mon, Feb 28, 2011 at 2:05 PM, Bryan Holladay <holladay at longsight.com>wrote:
> John,
>
> That looks like the old synoptic count query. If you are running msgcntr
> 2.7.x, you need to make sure you are pointing to the correct msgcntr
> synoptic tool. You should see MessageForumSynopticBeanLite
> in messageforums-app/src/webapp/jsp/synoptic/wait.jsp.
>
> I'm not sure how it could have been switch without manually changing the
> code. The old synoptic count query that has a known history of not scaling.
> Msgcntr 2.7+ doesn't call this query since it uses a different method for
> getting the synoptic counts.
>
> Thanks,
> Bryan
>
>
> On Feb 28, 2011, at 3:44 PM, John Bush wrote:
>
> This looks like the same thing that's been causing us some problems as
> well. Below is the query that was killing us, and then the indices that we
> added to addressed it. This is for 2.7.x code base.
>
>
> SELECT
> areaimpl4_.CONTEXT_ID AS col_0_0_,
> membership2_.NAME AS col_1_0_,
> COUNT(*) AS col_2_0_
> FROM MFR_MESSAGE_T messageimp0_ INNER
> JOIN MFR_TOPIC_T topicimpl1_ ON messageimp0_.surrogateKey=topicimpl1_.ID
> INNER
> JOIN MFR_MEMBERSHIP_ITEM_T membership2_ ON
> topicimpl1_.ID=membership2_.t_surrogateKey INNER
> JOIN MFR_OPEN_FORUM_T openforumi3_ ON
> topicimpl1_.of_surrogateKey=openforumi3_.ID INNER
> JOIN MFR_AREA_T areaimpl4_ ON openforumi3_.surrogateKey=areaimpl4_.ID,
> MFR_PERMISSION_LEVEL_T permission5_ WHERE ( areaimpl4_.CONTEXT_ID IN
> ('31d5c228-9a23-4008-901c-e82954b73f72' ,
> '31ca5050-f24a-48f3-a9a9-9cc1d685b62a' ,
> '9dd69181-76ec-4f6f-b058-40dcd01b159d' ,
> '24a3db03-8bcc-4545-8666-109068368366' ,
> 'bf2f0554-6cd8-4c0a-9c88-116867a258b9') )
> AND openforumi3_.DRAFT=0 AND topicimpl1_.DRAFT=0 AND messageimp0_.DRAFT=0
> AND messageimp0_.DELETED=0 AND ( membership2_.NAME IN ('Student') )
> AND
> (
> permission5_.TYPE_UUID<>'ad5db598-0ced-453a-9201-44403971e6e2'
> AND permission5_.NAME=membership2_.PERMISSION_LEVEL_NAME
> OR membership2_.PERMISSION_LEVEL=permission5_.ID
> )
> AND permission5_.X_READ=1 AND ( permission5_.MODERATE_POSTINGS=1
> OR messageimp0_.APPROVED=1
> OR messageimp0_.CREATED_BY='b3e0582f-e74f-4cba-a597-6010c6c829be' )
> GROUP BY
> areaimpl4_.CONTEXT_ID ,
> membership2_.NAME;
>
> create index mfrmessageindex2 on mfr_message_t (CREATED_BY);
> create index MFRMEMITEM_COMPOSITE_IDX1 on MFR_MEMBERSHIP_ITEM_T (NAME,
> PERMISSION_LEVEL_NAME, PERMISSION_LEVEL);
> create index MFRPERMLVL_COMPOSITE_IDX1 on MFR_PERMISSION_LEVEL_T (NAME,
> TYPE_UUID);
> create index CONTEXT_ID on MFR_AREA_T (CONTEXT_ID(10));
>
> On Mon, Feb 28, 2011 at 10:47 AM, Anthony Whyte <arwhyte at umich.edu> wrote:
>
>> I spoke with Ciellie earlier today and NWU's issues may well be related to
>> msgcntr performance issues. See email thread below.
>>
>> Cheers,
>>
>> Anthony
>>
>>
>>
>> Begin forwarded message:
>>
>> *From: *Bryan Holladay <holladay at longsight.com>
>> *Date: *February 28, 2011 10:04:55 AM EST
>> *To: *Anthony Whyte <arwhyte at umich.edu>
>> *Cc: *Sam Ottenhoff <ottenhoff at longsight.com>, "Michelle R. Wagner" <
>> wagnermr at iupui.edu>, Ian Dolphin <iandolphin at sakaifoundation.org>,
>> Ciellie van Vuuren Jansen <Ciellie.JansenVanVuuren at nwu.ac.za>, Pretorius
>> Boeta <Boeta.Pretorius at nwu.ac.za>, Lotter Adelle <Adelle.Lotter at nwu.ac.za>,
>> Alan Berg <A.M.Berg at uva.nl>
>> *Subject: **Re: [Building Sakai] Mysql high load Hibernate*
>>
>> I've done a lot of work with msgcntr performance setup.
>>
>> My first suggestion is to run a newer version of msgcntr. Since 2.7.0,
>> there has been a lot of code changes that have improved the performance,
>> with 2.7.3 having the latest updates. Msgnctr 2.7.x (2.7.0, 2.7.1, ...) and
>> even the Msgcntr 2.8.0 release coming up can run in Sakai 2.6.x. (* 2.8
>> requires a javascript file to be added to /resources, buts thats really
>> simple). We have done this for one of our clients and I did this for IU as
>> well in 2.6.x. It just takes some pom tweaks, which I can show you what we
>> did. Obviously, if you update, you will need to run the msgcntr update
>> script found in the code.
>>
>> The second suggestion is to remove all indexes for MFR_AREA_T,
>> MFR_UNREAD_STATUS_T, MFR_MESSAGE_T, MFR_TOPIC_T, and MFR_OPEN_FORUM_T. Then
>> add the correct minimal indexes to ensure that you only have the few indexes
>> that are needed. A lot of times people will add extra indexes thinking it
>> helps, but it usually just trumps the specific indexes and ends up running
>> slower.
>>
>> Theses are the ones you will need:
>>
>> ALTER TABLE MFR_UNREAD_STATUS_T
>> ADD CONSTRAINT TOPIC_C
>> UNIQUE (TOPIC_C, MESSAGE_C, USER_C);
>>
>> ALTER TABLE MFR_MESSAGE_T
>> ADD CONSTRAINT FK80C1A316A2D0BE7B
>> FOREIGN KEY(surrogateKey)
>> REFERENCES MFR_TOPIC_T(ID);
>>
>> ALTER TABLE MFR_TOPIC_T
>> ADD CONSTRAINT FK863DC0BE74C7E92B
>> FOREIGN KEY(of_surrogateKey)
>> REFERENCES MFR_OPEN_FORUM_T(ID);
>>
>> ALTER TABLE MFR_OPEN_FORUM_T
>> ADD CONSTRAINT FKC17608478B5E2A2F
>> FOREIGN KEY(surrogateKey)
>> REFERENCES MFR_AREA_T(ID);
>>
>> ALTER TABLE MFR_AREA_T
>> ADD CONSTRAINT MFR_AREA_CONTEXT_UUID_UNIQUE
>> UNIQUE (CONTEXT_ID, TYPE_UUID);
>>
>>
>>
>> To test your results you can use this query. It should run in 10ms or
>> less. If you do a "Describe" on that query, you should only see a few (2 or
>> so) row reads, the rest should rely on indexes:
>>
>>
>> select SQL_NO_CACHE unreadstat1_.USER_C as col_0_0_, count(*) as col_1_0_
>> from MFR_MESSAGE_T messageimp0_
>> inner join MFR_TOPIC_T topicimpl2_ on
>> messageimp0_.surrogateKey=topicimpl2_.ID
>> inner join MFR_OPEN_FORUM_T openforumi3_ on
>> topicimpl2_.of_surrogateKey=openforumi3_.ID
>> inner join MFR_AREA_T areaimpl4_ on
>> openforumi3_.surrogateKey=areaimpl4_.ID, MFR_UNREAD_STATUS_T unreadstat1_
>> where messageimp0_.ID=unreadstat1_.MESSAGE_C and
>> areaimpl4_.CONTEXT_ID='--add site id---'
>> and unreadstat1_.READ_C=1 and messageimp0_.DRAFT=0 and
>> messageimp0_.DELETED=0
>> group by unreadstat1_.USER_C;
>>
>>
>>
>> Let me know if you have any additional questions.
>>
>> Thanks,
>> Bryan
>>
>>
>> Begin forwarded message:
>>
>> *From: *Anthony Whyte <arwhyte at umich.edu>
>> *Date: *February 28, 2011 9:51:49 AM EST
>> *To: *Sam Ottenhoff <ottenhoff at longsight.com>, Bryan Holladay <
>> holladay at longsight.com>, "Michelle Wagner R." <wagnermr at iupui.edu>
>> *Cc: *Alan Berg <a.M.Berg at uva.nl>, Ciellie van Vuuren Jansen <
>> Ciellie.JansenVanVuuren at nwu.ac.za>
>> *Subject: **Fwd: [Building Sakai] Mysql high load Hibernate*
>>
>> Info from NWU:
>>
>> *Excerpts from NWU's slow-query log*
>>
>> Time: 110228 16:06:45
>> # *User at Host:* sakai[sakai] @ sakai-ap-lnx2.nwu.ac.za [143.160.38.174]
>> # Query_time: 3 Lock_time: 0 Rows_sent: 2 Rows_examined: 967383
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_
>> from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T
>> privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join
>> MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where
>> privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in
>> ('0b7939bd-4c61-47d0-a708-92491ace3940' ,
>> '84edb42f-5fc6-493d-bd36-65fc955df9b0')) and
>> privatetop0_.TITLE='pvt_received' and owner='23166797';
>> ^[# Time: 110228 16:07:05
>> # *User at Host:* sakai[sakai] @ sakai-ap-lnx2.nwu.ac.za [143.160.38.174]
>> # Query_time: 4 Lock_time: 0 Rows_sent: 1 Rows_examined: 967382
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_
>> from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T
>> privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join
>> MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where
>> privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in
>> ('053419fd-3798-4d84-be55-16fe8eac7ff0' ,
>> 'e79c1ca2-2faa-47ba-aa65-437783a055a8' ,
>> 'd27f0950-eebc-426f-bb82-53e0615d6a2c' ,
>> '3f893c87-d3eb-4b19-b955-a69dfe6e298b' ,
>> 'bdc482eb-e173-45e3-00e3-6d98a90d4cde' ,
>> 'ee6c4a82-131d-41e7-80cb-e17d3d785398' ,
>> '247bc8e8-4d17-48aa-a281-08e1868171df' ,
>> 'c0c31929-00d9-443e-8aba-ab079b81c321' ,
>> '1549a459-ac6b-4bc1-8c7e-d95076101009' ,
>> '4e4a2cc0-edd5-4103-a75e-babdbf8c7e56')) and
>> privatetop0_.TITLE='pvt_received' and owner='22730656';
>> # *User at Host:* sakai[sakai] @ sakai-ap-lnx1.nwu.ac.za [143.160.38.172]
>> # Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 967390
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_
>> from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T
>> privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join
>> MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where
>> privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in
>> ('bdc482eb-e173-45e3-00e3-6d98a90d4cde' ,
>> 'fe3dd099-f436-4a7e-99fe-c4562421aca5' ,
>> 'a27961f7-f81b-4fd3-913a-90dfc7fa467e' ,
>> '83b9d392-b078-4a33-b107-66f617d4dc12' ,
>> '500ac794-7aeb-45b7-ae4c-7909ca963edc' ,
>> '186e9e91-58b3-4d6d-8814-0a9fc8929db8' ,
>> '08c565bd-8aef-4ee4-8a3e-690ac0961c8c' ,
>> '1b6cef18-a082-413d-8c3a-fb48ca69bcc1' ,
>> '4eef1175-e6e8-40ae-abfd-660fbdcde5ce')) and
>> privatetop0_.TITLE='pvt_received' and owner='22118225';
>> # Time: 110228 16:07:06
>> # *User at Host:* sakai[sakai] @ sakai-ap-lnx2.nwu.ac.za [143.160.38.174]
>> # Query_time: 3 Lock_time: 0 Rows_sent: 4 Rows_examined: 967391
>> select areaimpl2_.CONTEXT_ID as col_0_0_, privatetop0_.UUID as col_1_0_
>> from MFR_TOPIC_T privatetop0_ left outer join MFR_PRIVATE_FORUM_T
>> privatefor1_ on privatetop0_.pf_surrogateKey=privatefor1_.ID left outer join
>> MFR_AREA_T areaimpl2_ on privatefor1_.surrogateKey=areaimpl2_.ID where
>> privatetop0_.TOPIC_DTYPE='PT' and (areaimpl2_.CONTEXT_ID in
>> ('f2024590-94d3-4978-a76f-586fdbcc6357' ,
>> '06129cd1-7eae-4a54-804c-ba18a504bf6f' ,
>> '78a0d8b6-49ea-4538-002a-82a1d8cdd379' ,
>> '5390ed6e-46d9-40d9-a3fa-489138fa66d2' ,
>> '8279b118-eb1e-4b7b-9642-18d5d519e4c2' ,
>> 'ee9a6627-eb43-4d60-8999-1d08c015b47a' ,
>> 'bc47a7c4-31f4-444f-9c08-308b2d683862' ,
>> '14eb7ecc-bc4b-4e28-805a-6d9b4aa9148c' ,
>> '47ba8813-b9b8-4af1-bce7-1d3a65e53905' ,
>> 'added142-fdd2-411f-8a8a-8c84c1d30eac' ,
>> '83b9d392-b078-4a33-b107-66f617d4dc12' ,
>> '49e48bfa-d666-4f4a-89b9-68853e860f95')) and
>> privatetop0_.TITLE='pvt_received' and owner='20744471';
>>
>> *Indexes on our prod db*
>>
>> MFR_AREA_T PRIMARY ID
>> MFR_ATTACHMENT_T,0,PRIMARY,1,ID,A,10188,,,,BTREE,
>>
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE7DEF8466,1,t_surrogateKey,A,10188,,,YES,BTREE,
>>
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE82FAB29,1,pf_surrogateKey,A,10188,,,YES,BTREE,
>>
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE5B252FAE,1,of_urrogateKey,A,10188,,,YES,BTREE,
>>
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE74C7E92B,1,of_surrogateKey,A,10188,,,YES,BTREE,
>>
>> MFR_ATTACHMENT_T,1,FK7B2D5CDE58F99AA5,1,m_surrogateKey,A,10188,,,YES,BTREE,
>> MFR_DATE_RESTRICTIONS_T Primary ID
>> MFR_LABEL_T,0,PRIMARY,1,ID,A,0,,,,BTREE,
>> MFR_LABEL_T,1,FKC661154329B20882,1,df_surrogateKey,A,,,,YES,BTREE,
>> MFR_LABEL_T,1,FKC661154320BD9842,1,dt_surrogateKey,A,,,,YES,BTREE,
>> MFR_MEMBERSHIP_ITEM_T,0,PRIMARY,1,ID,A,84352,,,,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,0,PERMISSION_LEVEL,1,PERMISSION_LEVEL,A,84352,,,YES,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CBA306F94D,1,a_surrogateKey,A,84352,,,YES,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CB7DEF8466,1,t_surrogateKey,A,12050,,,YES,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CB88085F8E,1,PERMISSION_LEVEL,A,84352,,,YES,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,1,FKE03761CB74C7E92B,1,of_surrogateKey,A,84352,,,YES,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,1,MFR_MEMBERSHIP_ITEM_I01_I,1,t_surrogateKey,A,12050,,,YES,BTREE,
>>
>> MFR_MEMBERSHIP_ITEM_T,1,MFR_MEMBERSHIP_ITEM_I02_I,1,a_surrogateKey,A,84352,,,YES,BTREE,
>> MFR_MESSAGE_T,0,PRIMARY,1,ID,A,41867,,,,BTREE,
>> MFR_MESSAGE_T,1,FK80C1A31650339D56,1,IN_REPLY_TO,A,41867,,,YES,BTREE,
>> MFR_MESSAGE_T,1,FK80C1A316A2D0BE7B,1,surrogateKey,A,20933,,,YES,BTREE,
>> MFR_MESSAGE_T,1,MFR_MESSAGE_DELETED_I,1,DELETED,A,2,,,,BTREE,
>>
>> MFR_MESSAGE_T,1,MFR_MESSAGE_T_IN_REPLY_TO_I,1,IN_REPLY_TO,A,41867,,,YES,BTREE,
>> MFR_OPEN_FORUM_T,0,PRIMARY,1,ID,A,1031,,,,BTREE,
>> MFR_OPEN_FORUM_T,1,FKC17608478B5E2A2F,1,surrogateKey,A,515,,,YES,BTREE,
>> MFR_PERMISSION_LEVEL_T Primary ID
>> MFR_PRIVATE_FORUM_T,0,PRIMARY,1,ID,A,241116,,,,BTREE,
>>
>> MFR_PRIVATE_FORUM_T,1,FKA9EE57548B5E2A2F,1,surrogateKey,A,4822,,,YES,BTREE,
>> MFR_PVT_MSG_USR_T,0,PRIMARY,1,messageSurrogateKey,A,22528,,,,BTREE,
>> MFR_PVT_MSG_USR_T,0,PRIMARY,2,user_index_col,A,1622033,,,,BTREE,
>>
>> MFR_PVT_MSG_USR_T,1,FKC4DE0E1473D286ED,1,messageSurrogateKey,A,22528,,,,BTREE,
>> MFR_TOPIC_T,0,PRIMARY,1,ID,A,726356,,,,BTREE,
>> MFR_TOPIC_T,1,FK863DC0BE82FAB29,1,pf_surrogateKey,A,242118,,,YES,BTREE,
>> MFR_TOPIC_T,1,FK863DC0BEFF3B3AE9,1,pt_surrogateKey,A,726356,,,YES,BTREE,
>> MFR_TOPIC_T,1,FK863DC0BE74C7E92B,1,of_surrogateKey,A,726356,,,YES,BTREE,
>> MFR_TOPIC_T,1,MFR_TOPIC_T_UUID_I,1,UUID,A,726356,,,,BTREE,
>> MFR_UNREAD_STATUS_T,0,PRIMARY,1,ID,A,221026,,,,BTREE,
>> MFR_UNREAD_STATUS_T,1,MFR_UNREAD_STATUS_I2,1,MESSAGE_C,A,18418,,,,BTREE,
>> MFR_UNREAD_STATUS_T,1,MFR_UNREAD_STATUS_I2,2,USER_C,A,221026,,,,BTREE,
>> MFR_UNREAD_STATUS_T,1,MFR_UNREAD_STATUS_I2,3,READ_C,A,221026,,,,BTREE,
>>
>>
>> Begin forwarded message:
>>
>> *From: *Anthony Whyte <arwhyte at umich.edu>
>> *Date: *February 28, 2011 9:48:42 AM EST
>> *To: *Sam Ottenhoff <ottenhoff at longsight.com>, Bryan Holladay <
>> holladay at longsight.com>, "Michelle R. Wagner" <wagnermr at iupui.edu>
>> *Cc: *Ian Dolphin <iandolphin at sakaifoundation.org>, Ciellie van Vuuren
>> Jansen <Ciellie.JansenVanVuuren at nwu.ac.za>, Pretorius Boeta <
>> Boeta.Pretorius at nwu.ac.za>, Lotter Adelle <Adelle.Lotter at nwu.ac.za>, Alan
>> Berg <A.M.Berg at uva.nl>
>> *Subject: **Fwd: [Building Sakai] Mysql high load Hibernate*
>>
>> Sam, Bryan, Michelle--I just spoke to Ciellie Jansen van Vuuren at NWU
>> (SA). From our discussion it appears that one source (if not the source) of
>> NWU's problems lie with msgcntr. The bulk of slow queries in the slow query
>> log are nearly all msgcntr-related.
>>
>> I've asked Ciellie to provide the following information for review:
>>
>> 1. Sakai CLE version: 2.6.2 ? (please confirm)
>> 2. msgcntr version: 2.6.2 ? (please confirm)
>> 3. msgcntr excerpts from the slow queries log
>> 4. A list of msgcntr indexes that she has applied. Given Hibernate, I
>> suspect she may be missing some.
>> 5. Any msgcntr patches she has applied.
>>
>> Reviewing Jira, none of the fixes that culminated in msgcntr-2.7.2 and
>> then msgcntr-2.7.3 have been back ported to 2.6.x:
>>
>> I. msgcntr-2.7.3 (addressed 2 tickets)
>>
>>
>> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVersion+%3D+%222.7.3%22+AND+project+%3D+MSGCNTR
>>
>> Includes MSGCNTR-388 (User's display name can freeze forums):
>> https://jira.sakaiproject.org/browse/MSGCNTR-388 (not in 2.6.x but UMich
>> has patched their msub 2.6.x with this fix)
>>
>> II. msgcntr-2.7.2 (addressed 12 tickets)
>>
>>
>> https://jira.sakaiproject.org/secure/IssueNavigator.jspa?reset=true&jqlQuery=fixVersion+%3D+%222.7.2%22+AND+project+%3D+MSGCNTR
>>
>> This release includes all tasks associated with the now infamous
>> MSGCNTR-361: https://jira.sakaiproject.org/browse/MSGCNTR-361
>>
>> Sam--I recall you mentioning that Longsight had a msgcntr 2.6 branch that
>> included all the performance improvements that are in 2.7.x. Can NWU
>> utilize that branch?
>>
>> Second, if you regard your branch code as stable I'd like to begin merging
>> appropriate fixes to 2.6.x. We should discuss which of the
>> msgcntr-2.7.2/2.7.3 fixes I should target.
>>
>> Cheers,
>>
>> Anthony
>>
>>
>> North West University deployment data *
>> https://jira.sakaiproject.org/browse/PROD-9
>>
>> * out-of-date at the moment, I've asked NWU to update it so that it
>> provides an accurate summary of their current production environment.
>>
>>
>> Begin forwarded message:
>>
>> *From: *Ciellie Jansen van Vuuren <ciellie.jansenvanvuuren at nwu.ac.za>
>> *Date: *February 28, 2011 5:04:48 AM EST
>> *To: *sakai-dev at collab.sakaiproject.org
>> *Subject: **[Building Sakai] Mysql high load Hibernate*
>>
>> Hallo
>>
>> We're running sakai 2.6 in production. The number of simultaneous users
>> almost
>> double from January causing our db to crash. We are caching queries and
>> try to
>> minimize slow queries, but still it crashes. Is it possible to let
>> hibernate
>> split reads and writes to different database servers. We are using Mysql.
>>
>> If it is what can we do to implement something like this?
>>
>> Thank you
>> Ciellie
>>
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>>
>>
>> On Feb 28, 2011, at 11:57 AM, John Bush wrote:
>>
>> Can you provide more information, what does your cluster look like, how
>> many users are you running concurrently on each tomcat? What tools are used
>> heavily, do you have particular slow queries that are causing you an issue?
>> Its quite possible a few additional indices might go a long way, but would
>> need to know a little more first.
>>
>> On Mon, Feb 28, 2011 at 3:04 AM, Ciellie Jansen van Vuuren <
>> ciellie.jansenvanvuuren at nwu.ac.za> wrote:
>>
>>> Hallo
>>>
>>> We're running sakai 2.6 in production. The number of simultaneous users
>>> almost
>>> double from January causing our db to crash. We are caching queries and
>>> try to
>>> minimize slow queries, but still it crashes. Is it possible to let
>>> hibernate
>>> split reads and writes to different database servers. We are using Mysql.
>>>
>>> If it is what can we do to implement something like this?
>>>
>>> Thank you
>>> Ciellie
>>>
>>> _______________________________________________
>>> sakai-dev mailing list
>>> sakai-dev at collab.sakaiproject.org
>>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>>
>>> TO UNSUBSCRIBE: send email to
>>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>>> "unsubscribe"
>>>
>>
>>
>>
>> --
>> John Bush
>> 602-490-0470
>> _______________________________________________
>> sakai-dev mailing list
>> sakai-dev at collab.sakaiproject.org
>> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>>
>> TO UNSUBSCRIBE: send email to
>> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
>> "unsubscribe"
>>
>>
>>
>
>
> --
> John Bush
> 602-490-0470
> _______________________________________________
> sakai-dev mailing list
> sakai-dev at collab.sakaiproject.org
> http://collab.sakaiproject.org/mailman/listinfo/sakai-dev
>
> TO UNSUBSCRIBE: send email to
> sakai-dev-unsubscribe at collab.sakaiproject.org with a subject of
> "unsubscribe"
>
>
>
--
John Bush
602-490-0470
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://collab.sakaiproject.org/pipermail/sakai-dev/attachments/20110228/41b1c079/attachment.html
More information about the sakai-dev
mailing list