[GENERAL] Re: [GENERAL] Re: [GENERAL] Fwd: Help!Why CPU Usage and LoadAverage Jump up Suddenly

2013-12-05 Thread Matt Daw
Is khugepaged running during the stalls?
http://www.postgresql.org/message-id/20130716195834.8fe5c79249cb2ff0d4270...@yahoo.es

Matt

On Thu, Dec 5, 2013 at 7:44 AM, Scott Marlowe scott.marl...@gmail.com wrote:
 On Thu, Dec 5, 2013 at 1:46 AM, 吕晓旭 lxxstc...@gmail.com wrote:



 Hi, all
 We find so weird problem on our productive PostgreSQL system. And I 
 don't know how could I do to resolve this problem.
 We deployed PostgreSQL 9.2.4 on two system environments,  and the 
 performances between them are absolutely different. one of them it's 
 perfect, and the other one lets me down, CPU Usage and LoadAverage Jumped up 
 Suddenly when concurrency smoothly rising up, simultaneously, average 
 response time become unacceptable.
 Anyone, who could give me some advice?

 The parameters of system environment and PotgreSQL listed below:

 Have you tried  monitoring your IO subsystem when this happens? I'd be
 interested in iostat, vmstat, iotop, and so on to see what the IO
 looks like.


 --
 Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
 To make changes to your subscription:
 http://www.postgresql.org/mailpref/pgsql-general


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


[GENERAL] Differences in Unicode handling on Mac vs Linux?

2013-06-02 Thread Matt Daw
Howdy, I loaded a client's DB on my Mac to debug an unrelated bug, but
I'm blocked because my Mac is rejecting SQL that works on our Linux
production servers. Here's a simple case:

# select * from shots where sg_poznÁmka is NULL;
ERROR:  column sg_pozn�mka does not exist
LINE 1: select * from shots where sg_poznÁmka is NULL;

... as far as I can tell, all my encodings are consistent on both
sides, I've checked LC_COLLATE, LC_CTYPE, client_encoding,
server_encoding and the database encodings. I'm running 9.0.13 on both
machines (and I tried 9.2.4 on my Mac).

Anything else I could double-check? Or are there any known Mac-related
Unicode issues?

Thanks!

Matt


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general


Re: [GENERAL] Differences in Unicode handling on Mac vs Linux?

2013-06-02 Thread Matt Daw
 Hm ... what does \d shots say about the spelling of the column name?

\d shots is the same on both systems:

 sg_poznÁmka  | text
 |


 OS X's Unicode locales are pretty crummy.  I'm suspicious that there's
 some sort of case-folding inconsistency here, but it's hard to say more
 (especially since you didn't actually tell us *which* locales you've
 selected on each machine).  If it is that, as a short-term fix it might
 help to double-quote the column name.

The locales are set to en_US.UTF-8 and encodings to UTF8. Double
quoting does solve the column case, but it's not helping with the
Rails generated:

SELECT a.attname, format_type(a.atttypid, a.atttypmod), d.adsrc, a.attnotnull
  FROM pg_attribute a LEFT JOIN pg_attrdef d
ON a.attrelid = d.adrelid AND a.attnum = d.adnum
 WHERE a.attrelid =
'asset_sg_kdo_děláassigned_to__connections'::regclass
   AND a.attnum  0 AND NOT a.attisdropped
 ORDER BY a.attnum

... that produces:

ERROR:  relation asset_sg_kdo_d�l�assigned_to__connections does not exist

\d produces:

 public | asset_sg_kdo_děláassigned_to__connections
| table| matt


For the short term, I think I'll boot up a Linux VM to troubleshoot my
production bug... but I'll submit a bug report with repro steps.

Thanks Tom!

Matt


-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general