Memory พอไหม

มาดูกันว่าค้นนี้เค้าตอบว่าอย่างไรบ้าง

> Mem:  16299476k total, 16198784k used,   100692k free,    73776k buffers
> Swap: 16787884k total,   148176k used, 16639708k free, 15585396k cached
>
>  PID   USER      PR  NI  VIRT    RES   SHR   S    %CPU  %MEM    TIME+    COMMAND
>  3401 postgres   20   0   4288m  3.3g    3.3g   S     0         21.1         0:24.73   postgres
>  3397 postgres   20   0   4286m  119m  119m  S     0        0.8           0:00.36   postgres

> PLease help me to understand how much memory does 1 Connection Uses and how
> to use Server parameters accordingly.

OK, first, see the 15585396k cached?  That's how much memory your OS
is using to cache file systems etc.  Basically that's memory not being
used by anything else right now, so the OS borrows it and uses it for
caching.

Next, VIRT is how much memory your process would need to load every
lib it might need but may not be using now, plus all the shared memory
it might need, plus it's own space etc.  It's not memory in use, it's
memory that might under the worst circumstances, be used by that one
process.  RES is the amount of memory the process IS actually
touching, including shared memory that other processes may be sharing.
 Finally, SHR is the amount of shared memory the process is touching.
so, taking your biggest process, it is linked to enough libraries and
shared memory and it's own private memory to add up to 4288Meg.  It is
currently actually touching 3.3G.  Of that 3.3G it is touching 3.3G is
shared with other processes.  So, the difference between RES and SHR
is 0, so the delta, or extra memory it's using besides shared memory
is ZERO (or very close to it, probably dozens or fewer of megabytes).

So, you're NOT running out of memory.  Remember when I mentioned
iostat, vmstat, etc up above?  Have you run any of those?





เดี๋ยวมารอดู iostat กันต่อ

Write locally, Read Globally

จากแนวคิดนี้ fb engineer ก็สามารถนำมาใช้งานกับระบบที่เรามีอยู่ได้ง่าย ๆ ก็คือการปล่อยการ update ข้อมูลเป็นของระบบฐานข้อมูลไป ส่วนการอ่านค่ามาใช้งานก็ให้อ่านได้จากหลาย ๆ ฐานข้อมูล

At Facebook, traditionally, writes are applied to one database and asynchronously replicated to databases across all regions. This makes sense as the write rate is normally much lower than the read rate (users consume content much more than they produce). A good way to think of this approach is "read locally, write globally".

Basic has no boundaries.

Postgresql เมื่อ index bloat (บวม)

เมื่อเราใช้ Postgres ไปนาน ๆ แล้ว สิ่งที่ติดตามมาคือ

1. จำนวน record ที่เพิ่มมากขึ้น
2. ขนาดของ index ที่มากขึ้น
3. ขนาดของ dead rows ที่มากขึ้น
4. ค่า free space map ดูว่าจะไม่พอแล้ว ในเวอร์ชั่นที่ต่ำกว่า 8.4
5. มันสายไปแล้วถ้าคุณลืมเปิด autovacumm

หลาย ๆ คน อาจต้องยอมทำ VACUUM FULL แต่ปัญหาก็ตามมาคือ ระบบผมหยุดไม่ได้!

ส่ิงที่ต้องรีบดำเนินการโดยด่วนคือ

1. เพิ่ม free space map
2. เปิด auto vacuum
3. จากเดิมที่ใช้ DELETE TABLE tablename; ก็เปลี่ยนเป็น TRUNCATE TABLE tablename;

อ้างอิงจากอันนี้ http://gkoenig.wordpress.com/2009/11/24/postgres-and-bloated-table/

postgres and bloated table

November 24, 2009 in open source, PostgreSQL

From time to time there are news/messages about bloated tables in postgres and a thereby decreased performance of the database.

The postgres-wiki contains a view (extracted from a script of the bucardo project) to check for bloat in your database here

For a quick reference you can check your table/index sizes regularly and check the no. of tuples to assume where bloat comes in.

e.g. check size of your tables and indexes:

SELECT relname AS table_name,

pg_size_pretty(pg_relation_size(oid)) AS table_size,

pg_size_pretty(pg_total_relation_size(oid)) AS total_size

FROM pg_class

WHERE relkind in ('r','i')

ORDER BY pg_relation_size(oid) DESC;

check no. of tuples

SELECT relname, relkind, reltuples, relpages

FROM pg_class

ORDER BY relpages DESC;

If you’re facing such a situation you have to check your (auto)vacuum settings and if it’s working correctly.

Starting with Postgres 8.3.x the autovacuum daemon works reliable for most cases and should be enabled. On some workloads a manual vacuum is needed anyhow. In combination with setting the (auto)vacuum parameters you have to consider the Free Space Map (FSM) parameter.

Open your postgresql.conf and check it out (every parameter has a very good comment there):

* enable autovacuum and log every run > 1 sec.

autovacuum = on

log_autovacuum_min_duration = 1000

fine tune when autovacuum will check the tables. The number is the fraction of the table size which needs modified data to run an autovacuum.

Apart from the bloated-table/index stuff, for the query planner it is very important to have up-to-date statistics. If you need an analyze more often, shrink the number to e.g. autovacuum_analyze_scale_factor = 0.02 and the tables will be autoanalyzed more often

autovacuum_vacuum_scale_factor = 0.2

autovacuum_analyze_scale_factor = 0.1

prevent autovacuum from running too often

autovacuum_naptime = 1min #time between two runs

And don’t forget to check your postgresql.log file for any hints the database system provides.

Regarding bloated tables I detected something like:

WARNING: relation "public.table_one" contains more than "max_fsm_pages" pages with useful free space

HINT: Consider using VACUUM FULL on this relation or increasing the configuration parameter "max_fsm_pages"

A “normal” vacuum wouldn’t help in this case because it doesn’t release the pages to the os, they will only be marked as free in the FSM (Free Space Map).

If your FSM isn’t big enough your tables will be bloated even with running autovacuum and perhaps manual vacuum, because the pages with no longer needed data cannot be marked as free and therefore never be overwritten.

One solution would be to run a

vacuum full verbose analyze table_name

This “defragment”-command marks unused pages as “can be overwritten” and moves pages from the bottom into this marked pages. => The table size will shrink

! But be aware: vacuum full locks the table exclusive. Consider running this command in maintenance windows or during night.

You should also keep in mind to “defragment” bloated indexes with

REINDEX INDEX indexname # recreate index explicitly

REINDEX TABLE tablename # recreate all indexes for this table

framework!

ช่วง 2-3 สัปดาห์ที่ผ่านมาใช้เวลาส่วนใหญ่กับการทำความเข้าใจกับระบบ ERP ซึ่ง หลาย ๆ คนคงหาหนังสืออ่าน แต่ผมมีเวลาน้อย ก็เลยอ่านผ่านการใช้งานโปรแกรม

นอกจากแนวทางการสร้าง Sofware ที่เป็นแบบ Opensource แล้ว เมื่ออ่านเสร็จแล้วก็ค้นพบว่า การวางรากฐานที่ดีในการพัฒนานั้น จะทำให้ การต่อยอดของ Software มีประสิทธิภาพดีด้วย และสิ่งที่เรียกว่ารากฐานนั้นก็คือ FrameWork นั้นเอง

หลาย ๆ คน พัฒนา Application ไป ก็พยายามสร้าง function ต่าง ๆ ขึ้นมามากมาย ท้ายสุดก็เกิดเป็น Framework ในการพัฒนาขึ้นมา ซึ่งผมก็เป็นอย่างนั้นเหมือนกัน

แต่ที่น่าแปลกใจคือ คนริเริ่มพัฒนา OpenERP นั้น เค้าศึกษาขบวนการทางธุรกิจ ได้อย่างมากมายได้อย่างไร

How to Install OpenERP on Leopard 10.6.4 with VirtualENV

Over 2 weeks i spent time to install OpenERP on my MAC.
Luckily i found the way.

First i try to install all with python2.6. Unfortunately OpenERP 5.0.14 work well with python2.5. Please try my step

1. you need python2.5!
2. you need postgres
   
3. install VirtualENV from fink
4. cd
   
5. virtualenv openerp-py25
6. source openerp-py25/bin/activate
   
7. install these packages by pip or easy_install
   
• Babel
• Beaker
• CherryPy
• FormEncode
• Mako
• MarkupSafe
• PIL
• PyChart
• PyXML
• pydot
• pyparsing
• reportlab
• simplejson
• psycopg2
  
8. # Download openerp server
   
9. $ bzr branch lp:openobject-server/5.0 openerp-server-5.0
10. # Install openerp server
11. $ cd openerp-server-5.0
12. $ python setup.py install
    
13. # Download openerp web
    
14. $ bzr branch lp:openobject-client-web/5.0 openerp-web-5.0
15. # Install openerp web
    
16. $ cd openerp-web-5.0
17. $ python setup.py install
18. # Start Open Server and web
    
19. $ openerp-server --db_user=openuser --db_password=
20. $ openerp-web
21. #Open Safari > http://localhost:8080 with username admin password admin
    

ref: http://devteam.taktik.be/index.php?/archives/9-How-to-install-Open-ERP-5.0.0-on-Mac-OS-X-10.5-Leopard.html

ดูสถานะของ HW RAID ผ่าน Linux

วันนี้หลังจากติดตั้ง Linux Debian เรียบร้อยแล้ว สิ่งที่ตามมาคือเราจะรู้ได้อย่างไรว่า HW-RAID ของเรานั้นทำงานเป็นปกติดี

อันดับแรกก็ต้องตรวจสอบก่อนว่า เรามี HW รองรับหรือไม่

Server# dmesg |grep mpt
[ 2.174757] mptbase: ioc0: Initiating bringup
[ 3.369272] mptbase: ioc0: PCI-MSI enabled

เมื่อแน่ใจแล้วก็ติดตั้ง mpt-status (mpt-status - get RAID status out of mpt (and other) HW RAID controllers)

Server # aptitude install mpt-status

แต่เมื่อลองใช้งานดูปรากฏว่า ยังไม่มี device และยังไม่ได้โหลด module นี้ไว้ใน Kernel เลย
Server # mpt-status
open /dev/mptctl: No such file or directory
Try: mknod /dev/mptctl c 10 220
Make sure mptctl is loaded into the kernel

ดังนั้นก็เริ่มโหลดกัน

Server # mknod /dev/mptctl c 10 220
Server # modprobe mptctl

ดูหน่อยว่ามี module โหลดแล้วแน่
Server# dmesg |tail -n 3
[ 1786.460073] Fusion MPT misc device (ioctl) driver 3.04.06
[ 1786.460073] mptctl: Registered with Fusion MPT base driver
[ 1786.460073] mptctl: /dev/mptctl @ (major,minor=10,220)

Server# mpt-status

You seem to have no SCSI disks attached to your HBA or you have
them on a different scsi_id. To get your SCSI id, run:

mpt-status -p

Server# mpt-status -p
Checking for SCSI ID:0
Checking for SCSI ID:1
Found SCSI id=1, use ''mpt-status -i 1`` to get more information.

Server# mpt-status -i 1
ioc0 vol_id 1 type IM, 2 phy, 465 GB, state OPTIMAL, flags ENABLED
ioc0 phy 0 scsi_id 4 ATA ST3500514NS BB23, 465 GB, state ONLINE, flags NONE
ioc0 phy 1 scsi_id 2 ATA ST3500320NS BB12, 465 GB, state ONLINE, flags NONE


เท่านี้เราก็รู้ว่า RAID เราทำงานหรือยัง

สุดท้ายก็ต้องให้ mptctl โหลดตอน Boot

Server # vi /etc/modules

แล้วเพิ่ม mptctl เข้าไปอีก 1 บรรทัด

ที่มา http://linuxhostingsupport.net/blog/open-devmptctl-no-such-device-make-sure-mptctl-is-loaded-into-the-kernel

SMTP relay with authenticate

เวลาเราใช้ SPF ในการตรวจสอบที่มาของการส่ง email เราก็จะพบว่าต้องคอยไปเพิ่ม ip ของเครื่อง server ที่เราใช้ส่งอยู่บ่อยไป ดังนั้น มาวันนี้ก็ขอใช้ความรู้เรื่องการทำ authenticate relay smtp มาใช้งานดู ซึ่งสามารถใช้ได้กับ smtp ของ gmail ได้ด้วย (นี่ยิ่งทีเข้าไปใหญ่)

ก่อนอื่นเราต้องแน่ใจก่อนว่าเรามีการใช้งาน sasl ก่อน

# sudo apttitude install postfix libsasl2-2 ca-catificate libsasl2-modules

แล้วก็ต้องมาแก้ main.cf ตามมา โดยให้มีการกำหนดค่าสำคัญ ๆดังต่อไปนี้

[สร้างไฟล์ /etc/postfix/sasl_passwd.db]

Server # vi /etc/postfix/sasl_passwd
 # [smtp.mydomain.com]:25 user.name@mydomain.com:password

Server # chmod 400 /etc/postfix/sasl_passwd

Server # postmap /etc/postfix/sasl_passwd #เราก็จะได้ไฟล์ sasl_passwd.db ออกมาใช้งาน

[สร้างไฟล์เพื่อใช้สำหรับการตรวจสอบ certificate]

Server # cat /etc/ssl/certs/Thawte_Premium_Server_CA.pem | tee -a /etc/postfix/cacert.pem

[main.cf]

relayhost=[mail.mydomain.com]:25

smtp_use_tls=yes

smtp_sasl_auth_enable = yes

smtp_tls_loglevel=1

smtp_sasl_security_options = noanonymous

smtp_sasl_local_domain =

broken_sasl_auth_clients = yes # ไว้สำหรับ MS Outlook ดีนักแล

smtp_sasl_password_maps = hash:/etc/postfix/sasl_passwd

smtp_sasl_authenticated_header = yes # สำหรับบอกว่า email นี้ได้ผ่านการตรวจสอบผู้ใช้แล้วนะ

smtp_tls_CAfile = /etc/postfix/cacert.pem # ไฟล์ Certificate

ที่มา : http://ubuntu-tutorials.com/2008/11/11/relaying-postfix-smtp-via-smtpgmailcom/