Friday, July 20, 2012

You don't need to backup information_schema database

You don't need to backup information_schema database, see:
http://dev.mysql.com/doc/refman/5.0/en/information-schema.html

information_schema is a virtual database, rebuilt each time MySQL is restarted, so there is no point in backing it up because you can't restore it anyway.

Thursday, July 19, 2012

innodb_file_per_table

innodb_file_per_table
Recently I attempted to use this parameter in one of our InnoDB table and had an experience to make a note of.

So this is what actually happened.
As we know InnoDB writes all the table information into one tablespace file ibdata1.
Obviously this lead to a disk space issue, since the ibdata1 file grew to 90G+ and it was not possible to defragment tablespace using the Alter method (Infact is is hardly possible to do in a production environment, since it leads to a huge downtime.)

So I decided to go for innodb_file_per_table on our other production database server which was being configured from scratch.

Now this database had around 15 tables and it had very high inserts/deletes/updates. For few days, things went ok. But in few days, I started getting complains from development team regarding performance on the tables and queue being backed up. Apparently whenever a delete / update was made on a table, all the other tables slow down and queries started taking more than 4 to 5 secs to complete.

Dug around, ran some more optimisations , flush tables but not much difference. I was able to get 660 to 661 qps tops.

On digging further and discussing with developers, we figured out that innodb_file_per_table is the culprit.

InnoDB uses fsync() instead of fdatasync() to flush both data and log files on non-Windows system. fdatasync() is like fsync(), except it flushes only files data, not its metadata (last modified time etc.). Therefor fsync() can cause more IO.

innodb_file_per_table causes each file to be fsync()ed separately which means writes to multiple tables can't be combined into a single IO operation. This requires InnoDB to perform higher total number of fsync() operations, leading to a IO contention in my case.

Finally we had to migrate the database to another machine without innodb_file_per_table since it is also not possible to undo the existing tables for which files are created per table.

As quoted in MySQL documentation :

The --innodb_file_per_table option affects only table creation, not access to existing tables. If you start the server with this option, new tables are created using .ibd files, but you can still access tables that exist in the shared tablespace. If you start the server without this option, new tables are created in the shared tablespace, but you can still access any tables that were created using multiple tablespaces.

Once we migrated the performance started going up , almost upto 1500 qps.

So moral of the story : Better test the parameter innodb_file_per_table in a test environment, with the load higher than expected on production. I have read many blogs and many people are benefited by the use of this parametere, but as a general practice I would not favor its use. Sure it can be useful to reclaim some disk space, but I dont think it would be worth at the cost of performance.

Reference:
http://umangg.blogspot.ca/2010/02/innodbfilepertable.html

Saturday, July 14, 2012

關於創業,你必須知道的13件事


Paul Graham是個成功的創業家、程式設計師、知名部落客與科技寫手,多年來他在網路上發表了許多文章分享他對於創業或是科技領域的看法,他在2005年創辦了一家特別的創投公司Y Combinator後,這些文章也成了Y Combinator與所有網路創業團隊的指導教材,其中有一篇Startups in 13 Sentences提到Paul Graham總是跟創業團隊教導一個很重要的原則:
比起讓很多人感到一半的滿意(semi-happy),不如讓比較少的人感到真正的滿意(really happy)。
這個概念是Paul Graham從Paul Buchheit那學來的(Paul Buchheit是Gmail與Google AdSense產品的發起人與主要開發者),那麼除了這個重要的觀念之外,Paul Graham也思考如果只能給創業團隊10句話,另外9句話會是什麼呢?
後來,Paul Graham歸納出共13個重點,筆者除了試圖將Paul的觀點分享給各位讀者之外,也會融入Inside團隊成員實際在創業中的經驗,希望可以與各位讀者多交流相關經驗。

1. 找到好的共同創辦人(Pick good cofounders)

共同創辦人對於創業團隊來說,就跟你在找房地產時考慮地段、地點一樣重要。你可以改變房屋的裝潢、擺設,但你卻改變不了房子的所在地點。在創業團隊中也是,你的想法、創意是可以很輕易改變的,但把你的共同創辦人換掉卻非常困難。 事實上,每一個創業團隊的成功,幾乎都是團隊創辦人在團隊中發揮了作用。
筆者兩次參與創業團隊的經驗,我們都堅信一個信念:「只要這群兄弟還在,我們一定能做出什麼(do something big)」,創業沒有成功不等於失敗,創業沒有成功而直接放棄了才真的是失敗;只要團隊還在,或許只是想法錯了、方法錯了、對象錯了,但如果人是不對的,本質上就已經難以改變。

2. 速度要快(Launch fast)

速度要快的原因並不是說要讓你的產品盡早接觸市場,而是你必須真的將想法付諸實現後並推出產品,你才真的是在創業並實踐你的想法,這個過程也才可以讓你真正了解自己究竟做了些什麼,你也會發現或許有些事情你做了但其實是在浪費時間。無論你推出了一個怎樣的產品、創造了什麼價值,重點是早點有機會了解使用者的想法。
速度要快、保持敏捷很重要,郭台銘先生說:
在現今世界上,沒有「大」的打敗「小」的,只有「快」的打敗「慢」的
Joel Spolsky(Joel就是知名的約耳,你或許有聽過約耳談軟體,近來好像翻譯為周思博趣談軟體)也在「邊開火邊移動」(Fire and Motion)一文中這麼說:
對我們這種小公司來說,邊開火邊移動有兩個意義,你必須爭取時間,另外每天都得要前進,你遲早會贏的。
東西會愈來愈好,我們的軟體每天每天都會變得更好,而且客戶會愈來愈多,這就夠了。在我們變成Oracle這種規模的公司前都不用管什麼偉大的策略。我們只要每天早上來公司,想辦法要自己打開編輯器就好了。

3. 讓你的想法持續進化(Let your idea evolve)

讓想法持續進化與速度要快是一體兩面的,試著加快釋出產品的速度並且不斷的調整產品。如果你對於創業的設定就只是把一個一開始看起來很棒的想法實作出來,這肯定是個很大的錯誤。就跟寫作一樣,大部分的想法都是在寫作過程中才浮現出來的。
在實作的過程中,你會發現有更多好的想法持續浮現出來。Time to market很重要,筆者總認為「產品上線後才是另一個開始」、「產品上線後才是真正的開始」,事實上,在我們尚未真正推出產品前,我們做的事情很簡單:關在會議室中假設人們應該會喜歡什麼功能、不喜歡什麼功能。如果能盡早推出產品、持續調整路線,可以讓我們少走些冤枉路,即使是推出產品來證明自己想法錯誤,也是一種收穫、一種讓想法進化的方式。

4. 了解你的用戶(Understand your users)

你可以設想創業團隊所能創造的財富就像個矩形一樣,一邊是你的用戶人數,另一邊是你能改善他們生活的程度。尤其後者是你最能夠掌握的,事實上,你的用戶人數將會取決於你在後者所付出的努力程度。從科學的角度來說,最困難的部份往往不是回答一個問題,而是提出一個問題。創業也一樣,最困難的部份是看到使用者目前欠缺了什麼、需要什麼,身為一個創業者,你越能了解你的用戶,你就越能滿足用戶的需求。這也是為什麼很多成功的創業團隊都是先從打造創辦人自身需要的工具起家。
Inside上曾提過37signals這個成功的創業公司(37signals的37個創業心法),文中也提到:
解決自己的問題會讓你愛上你做的事(Solving your own problem lets you fall in love with what you’re making.)
俗諺也說:
吃你自己的狗食(Eating your own dog food)
筆者非常認同創業團隊可以先從打造一個能解決自有問題的工具開始,因為當我們所創造出來的資訊工具可以有效地解決我們自身的問題時,它或許也可以協助其他遇到相同困擾的團隊,更別說當我們開始進行行銷、銷售,我們更能設身處地的告訴我們的潛在消費者它是如何解決我們的問題的。

5. 讓少數的用戶愛上你的產品,而別讓很多人感到不滿(Better to make a few users love you than a lot ambivalent)

當然在理想的情況下,我們都會希望有非常多的用戶愛上自己所打造出來的產品,但你無法預期能否馬上達到這個目標。一開始你必須小心謹慎地在「滿足一部分潛在顧客的所有需求」與「滿足所有潛在顧客的部分需求」之間進行取捨。建議選擇前者,因為擴展用戶比起提昇滿意度來的容易。而且,更重要的是,如此一來你很難欺騙自己,如果你認為你正在打造一個很棒的產品,目前已經有85分了,你怎麼知道它在用戶眼中其實是70分?或是只有10分?相較之下,你很容易掌握你目前已經有多少客戶。
我們很難讓所有的人滿意,相較之下要讓少數人滿意似乎比較容易,假設已經有10個人對於我們的產品感到滿意,要再找出第11個人似乎也並不是那麼困難。而且,如果一開始設定要直接讓100個人感到滿意,很有可能只要有10個關鍵人物對於產品感到極度不滿,產品也不是沒有被一炮擊沉的可能。
或許,尋找一個適當的小眾市場、分眾或垂直的市場,會是一個比較容易掌握的開始。
“Niche first, world later”,許多知名的網站、產品,最初想要解決的問題都很簡單,以Facebook來說,它最早的定位僅僅是哈佛大學的校友通訊錄網站,在發展的過程中,Mark Zuckerberg很有耐心的一步一步從哈佛大學開始往外擴張,最後成為全球最大的社群網站之一。
這道理就像如果我們只適合打社區棒球隊,但卻硬要跑去打大聯盟,你認為花了大把銀子買票進場的觀眾們會滿意嗎?

6. 在客戶服務上提供一些意外的驚喜(Offer surprisingly good customer service)

顧客們已經習慣了在尋求客服協助時被虐待了。顧客們接觸到的多數公司,都是幾乎壟斷市場而且客服品質非常糟糕的。你或許也曾經因為遇到糟糕的客服而讓你以為客服就是這樣,而讓你在沒有意識到這是多麼糟糕的一件事情時,也提供了同樣品質的客服。不,顯然你必須做個更好,不只是要試著提供「好」客服,更要努力提供「令人感到驚喜」的好客服。盡你所能的讓人們感到滿意,他們一定會感到驚喜的。在創業的初期,試著在可以負擔的情況下提供好的客戶服務,因為這也是個了解客戶需求的好方法。
“Deliver beyond expectation”是筆者與創業夥伴們在打造產品、解決方案時期許團隊能夠達到的目標,總是給予客戶超乎他們預期的,讓客戶滿意並且藉此維繫良好關係,先照顧好既有的客戶,才思考如何拓展業務。

7. 記錄那些你在乎的事情,並且努力改善績效(You make what you measure)

這一招是Paul Graham從知名創業家Joe Kraus(現服務於Google Ventures)那學來的。如果你持續在記錄某些事情的發展狀況,你的潛意識會讓你想要去改善這些事情。例如,你想要增加你的使用者人數,那麼就在牆上貼一張大海報,每天都在上面記錄使用者人數的變化。
如果你發現曲線持續在上升,你會感到很開心;反之,如果你發現曲線正在下滑,你會感到失望。很快的你就會開始注意到究竟是什麼事情影響了這些數據,接著你就會開始做更多有助於提昇績效的事情。當然,你必須搞清楚你真正該關心的數據有哪些,不要本末倒置了。
當然,我們可以選擇土法煉鋼在牆上、白板上記錄這些數據,也可以利用數位科技,例如Google的網站流量分析工具就提供了Dashboard讓我們可以快速了解各個關於流量的重要數據;或是我們也曾經為各位讀者介紹過「使用Web技術打造IT績效儀表板(Dashboard)」,也是一種讓團隊成員們可以即時掌控關鍵數據的方式之一。

8. 錢,省著點花(Spend little)

節省創業團隊的開銷是很重要的。多數的創業團隊在還沒能做出人們想要的東西之前就會失敗,其中最常見的失敗原因就是資金短缺。因此,節省開銷就幾乎等同於速度要快一樣重要。而且,節省的文化可以讓公司保持年輕、活力,就跟人們藉由運動來保持年輕與活力是一樣道理。
每個創業團隊都想追求成功,但最後能被人們認為成功的團隊總是極少數。多數的團隊都沒有成功,如果團隊沒有成功並且瓦解、放棄創業,那麼幾乎就是失敗,也就是說有許多團隊最終都會失敗,因此「避免失敗」成為過去我與夥伴們在創業過程中很重要的目標之一。我們除了節省開銷、降低burn rate之外,我們也試圖建立穩定的營收,等於是開源節流,追求自給自足、損益兩平,避免團隊處在持續燒錢的狀態。

9. 先填飽肚子就夠了(Get ramen profitable)

“Ramen profitable”(Ramen就是拉麵)指的是創業團隊能滿足創辦人們的最低基本生活開銷。這並不是一種可以快速促使你的營運模式成形的方式(儘管理論上是可以的),但這更像是一種對於吸引投資的一種小技巧。一旦你的營收已經跨過了Ramen profitable的界線,這將會有利於改變你跟投資人之間的關係。當然,這也有助於提昇你的團隊士氣。
節省開銷的方式有好幾種,例如租用最便宜的辦公室與伺服器、能不花的錢就不花、所有創辦人都拿最低的薪資(甚至不拿),換句話說或許我們可以更容易達到損益兩平,從帳面上來看公司已經是沒有虧錢,並且在邁向獲利的情況,對投資人來說顯然不會只是把錢丟入一個錢坑開始燒錢,而是在協助團隊進行擴張(或是讓創辦人終於有加薪空間)。

10. 避免分心(Avoid distractions)

我們大概找不到其他因素比起「分心」更容易讓創業團隊招致失敗。最糟糕的狀況就是那些貌似可以幫創業團隊帶來一些營收的副業,包括全職的工作、顧問諮詢、外包案等等。長期來看或許創業團隊可以有更多潛在的機會,但在這過程中你必須為了應付客戶(花錢在你身上的老大們)而中斷你真正重要的工作。事實上,募資也是一種讓創業團隊分心的因素,所以能避免還是盡量避免吧!
目前我與夥伴們確實就處在「找到一些貌似可以帶來一些營收的副業」,包括一般的網頁外包案、顧問諮詢服務、伺服器代管,我們甚至很認真的將這些副業轉為團隊的主要業務內容之一,並規劃出一個部門在未來專門因應這類需求,持續創造公司的基本營收。畢竟,我們對於我們要做的產品究竟能否創造營收,並沒有十足的把握,在避免失敗的前提下,我們還是稍微分心了。
然而,在分心的過程,我們還是比較有結構、有方法的將分心的事情化為各種可以累積的資源與經驗也就是長期來講我們希望這些業務內容是有潛力發展出一些成果的,包括:
  • 我們建置了一套自有的CMS系統,根據多數的外包專案需求,幾乎可以量身打造各類網站,未來更打算將此CMS系統直接進行產品化放在線上提供服務
  • 我們實際導入虛擬化技術來協助客戶建置雲端架構平台,此架構並可直接運用於我們要打造的產品
  • 我們採用一些開放原始碼專案來協助我們管理伺服器、監控伺服器與各類服務的運作與負載狀況,透過這些過程來累積我們管理伺服器的經驗
當然,另一派說法是我們應該避免打工賺錢,專注在產品上,但畢竟我們不希望有任何夥伴在創業的過程因為經濟因素而退出,也不希望公司因為沒有營收而讓大家士氣低落、看不到未來。
有一次筆者與一位朋友聊到所謂創業精神(entrepreneurship),他給的回答讓筆者印象深刻:
創業最有趣也最具有挑戰的一點,就是即使你不是100%相信你的想法,你還是必須專注、努力去做
或許有了這樣的信念,會讓我們更專注的投入自己真正想做的事情並且有效地避免分心。

11. 不要洩氣(Don’t get demoralized)

創業團隊的失敗原因通常都是因為資金短缺,但背後可能還有更深層的原因:失去焦點,可能是公司給一群笨蛋領導(而且大家給的建議還聽不進去),或是公司給一群聰明人領導,但這群聰明人最後卻洩氣了。投入創業需要的是強大的心理素質、抗壓性,你必須很清楚這點並且小心試圖別被擊倒,就好像你在搬一個很重的箱子時,你也會小心翼翼的彎著你的膝蓋,好讓自己穩一些。
盧彥勳在溫布頓網球賽對上Andy Roddick的最後幾球,憑藉著過人的穩定性與心理素質,讓他即使是遇上這位世界頂尖的網球好手也無所畏懼並且能有一流表現。我認為,可以在最後勝出的關鍵因素在於過人的心理素質,在面對強敵時、面臨低潮時仍能堅定意志、專注的繼續努力。
此外,現在的表現不好,不見得是產品不好,很可能只是時機不對或是運氣不好,或許我們應該要沉得住氣,等待機會的降臨並把握住。「深蓄厚養,待時而動」也是一招。

12. 不要放棄(Don’t give up )

即使你感到洩氣了,也千萬不要放棄。只要不放棄,就還有希望,儘管並非所有事情都可以這麼想,就像有些人就算再努力、堅持再久也沒辦法成為一個好的數學家。但是創業不一樣,只要你夠努力,並且持續調整你的想法。
我很佩服某些創業者,尤其具有強烈領導特質的創業者更是令人欽佩,隨時保持最強的心理狀態與團隊共事,他內心很清楚只要他先倒下了,這個團隊或許也會走入低潮期甚至瓦解,就算公司沒賺錢、最近成績不好,但他始終不放棄,筆者也希望自己可以鍛鍊出如此堅強的心理與領導特質。
說實在,若把時間拉長來看,要五年、十年才能達成的目標與成就,此時此刻的失敗、失意又算得了什麼,今天的一切都是為了更好的明天所做的準備

13. 失敗的交易就算了吧!(Deals fall through)

Paul Graham從過去創立Viaweb(Viaweb後來以將近5,000萬美元出售給Yahoo!成為後來的Yahoo! Store)學到的經驗之一是對於每一次交易不要期望太高。Viaweb當時有20筆交易是失敗的,一開始前10個客戶他們可能還會希望想些辦法努力一下拉住客戶,在那之後他們就決定不要去管這些拒絕他們的客戶了,就好像是電腦作業系統裡在背景執行的程序,反正他們該消失的時候就會自然消失,就別理了。如果過於指望每一次的訂單可以成交,這對於團隊士氣來說是很危險的,不要指望每一筆交易都成交,因為這是不可能的。
創業過程很有趣,以筆者過去的經驗來說,在創業初期幾乎是要同時當工程師、業務員、研究員,尤其在擔任業務角色的時候,被拒絕的經驗是很常有的,後來針對這種狀況也多見不怪,一方面對於每次的提案已經駕輕就熟可以快速完成一份提案來減少單一專案的事前付出,也就不會感到「花了那麼多時間準備一份好提案結果被拒絕」、避免得失心,另一方面,每次的拒絕都是自我檢討的好機會,讓自己可以持續的修正、調整業務的進行方式與提案內容。

結語:先從了解你的用戶開始吧!

Paul Graham提出的這13點經驗分享真的是很棒,讓筆者也藉此檢視了正在投入的創業團隊,是不是有哪些地方明顯做得不對、做得不好。Paul Graham也說,如果這13句話裡面只能選擇一句的話,他會選擇「了解你的用戶Understand your users.」這是創業團隊要開始創造營收很重要的關鍵。
當然,你必須速度很快、及早讓你的產品上市藉此來了解你的用戶,並且在過程中持續修正、進化你的想法,而且要試圖讓你那可能為數不多的用戶們滿意(really happy, instead of semi-happy),並且提供給他們超乎預期、感到驚喜的客戶服務,他們會對你的服務與產品喜愛的不得了並且去告訴他們的好朋友,像是「嘿!我上次用了Dropbox,真的是非常好用,趕快來用一下吧!」(Dropbox很好用是沒錯,但筆者相信更多人是為了邀請新朋友加入可以額外得到的250MB,it really works)
事實上Paul Graham給予創業團隊的心法絕對不是只有幾句話、幾篇文章就可以談完的,Inside部落格會持續為各位讀者介紹,如果你有任何心得想要發表、討論也歡迎隨時留言或來信交流。
Reference:

Wednesday, July 4, 2012

Disabling cross-domain security check for AJAX development in Google Chrome

This tip is for those who need to test Javascript / HTML5 web application functionality against a production server from their local HTML and Javascript files (not localhost).

Start Google Chrome with no security from command lin, OSX:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --disable-web-security

Start Google Chrome from command line, Ubuntu/Linux:

chromium-browser --disable-web-security

After this cross-domain AJAX requests work.

Also use

–allow-file-access-from-files

Reference:
http://opensourcehacker.com/2010/11/29/disabling-cross-domain-security-check-for-ajax-development-in-google-chrome/
http://peter.sh/experiments/chromium-command-line-switches/

Monday, July 2, 2012

UPS (Uninterruptible Power Supply) 的問題

UPS (Uninterruptible Power Supply) 的問題

請問使用UPS有什麼禁忌嗎?
知其我朋友說UPS上面不能插電風扇,不然會燒掉
這是真的嗎@@?
如果是真的還有哪些東西不能插在上面 [無奈]

還請問在線上互動式的UPS有比離線式嗎?賣家說有比較好

最近想買UPS的人~留
===
mikescchen

之前好像是說 線圈型的東西(馬達)
跟容易產生瞬間大電流的東西(典型:雷射印表機)不要接到UPS上面.

一個觀念, UPS不是讓你在停電的時候"繼續使用"的
而是幫你爭取"安全關機"的時間
所以簡單說.... 斷電也無所謂的東西 不要接就對了XD
另外, 稍微好一點的UPS都有自動關機軟體
可以設定斷電幾分鐘內沒有自己來電的話, 就把安裝軟體的設備關掉
人不在旁邊也沒關係.

UPS的種類嗎...
off-line的是, 平常電力分一些去充電, 充滿的話電就直接跳過UPS迴路到後面的設備.
好處是便宜, 壞處是無法改善電力品質(電壓不穩, 突波, 等)
而且UPS發現斷電的時候, 會需要一個反應時間把電路切到電池上面, 有些比較敏感的設備遇到這個反應時間會不行.
on-line的沒這個切換動作, 而且會對電源做處理(程度視機種而定), 可以有限度的改善電力品質.

我自己裝過的某美國牌小台UPS就已經有自動關機軟體了...
還會監測電力的狀態, 可以畫圖
設定關機時間的時候也會依照平常用電的量, 來估計說可以撐多久, 讓使用者參考. (雖然有貴一點啦XD)
===
harleyguo

我來稍微解釋一下為什麼有些UPS不能接電風扇(馬達)嘍

因為馬達這種東西剛啟動的時候電流都會特別大,阿不過還好家裡的插座裡的市電是正弦波,

也就是他有機會讓電風扇在剛插電(啟動)的時候是碰到0度時的電壓也就是0V,

要是插電的時候剛好在90度的正弦波時,會是電壓最高的時候,也就是啟動電流最大的時候

再來電風扇是一直轉的,至少轉個180度的時候,風扇裡的電刷會換相一次,每換相一次對馬達來說會是另一次的啟動

當然這另一次的啟動電流會比馬達從靜止啟動的電流來的小嘍

話說回來UPS,目前面上的UPS所輸出的交流電壓波形屬於"擬似正弦波",基本上是近似於方波的"凸"字型波

所以用在馬達類的電器時,以方波來講一啟動就不會是零了,而且在電刷換相的時候,電壓是從交流電的最小負電壓直接換到最高的正電壓,也就是兩倍的電壓,電流自然是兩倍....

講到這邊..那為什麼可以接PC的POWER咧,原因就是PC的POWER均屬於交換式電源供應器,也就是一定會有輸入電容(儲能電容)來做濾波,所以不管是什麼波都一定會濾成直流來給變壓器轉換成PC要用的電壓

有PFC設計的POWER當然就會對方波(或"凸"波)進行校正後再使用樓!!

以上,是個人經驗,提供大家參考!!
===
小建^^

請問是在線式
就可以插電風扇嗎@@?
如果真的享用UPS吹風扇的話該怎麼辦 [歹勢]

關燈時候PC啦叭跟著砰一聲,這個就是凸波嗎?
===
harleyguo

也不是說在線式就能用來吹電風扇
主要是要看UPS的規格中,輸出的波形是不是正弦波(sin波形)
比較簡單的UPS通常都不是正弦波來著
在線式UPS是將整個系統持續接在負載上,不管停電或不停電都是由UPS內部的直流電源轉換的交流電源來供應負載
離線式UPS在停電之前是由市電直接供應到負載的,等到停電時的前幾十個微秒才將電池的直流轉為交流電供應給負載
以上兩種都有將直流轉換成交流的過程,所以還是要看他的交流電是不是真正的正弦波,而非交流方波(有些為凸字型波),可以確定的是離線式負載在停電之前是可以使用在電扇上面的,停電後就要看輸出的波形了~(謎之音:那不如就直接插插座就好了)

另外開關燈的時候喇叭會有一個碰一聲,不是因為凸字型的波;原因為關燈的時候,供應到你家的電力會因為突然的降載使電壓稍微偏高一下下,讓原本已經在使用電源的電器會感受突然的電壓上升,產生一個突波(非凸字型波)
突波為正弦波上的一個諧坡,諧波當然就是不好的波嘍!!所以要是電器的規格標示中有一個CE的符號,那這個電器就不會受到其他電器開開關關的影響了
===
港都狼仔

私人訊息
引用連結
載入圖片

一般UPS於DC-AC上使用的是MOSFET固態換流器,連接電阻性負載(例如有加熱器的雷射印表機),因電阻性負載導通時電流是由高漸低,容易導致換流器在每一電壓相位輸出產生電流過大現象,容易觸動保護或是導致其損壞,而連接電感性負載(例如電風扇),會因為電感性負載電流落後電壓的情形下,使換流器功率因數下降,降低其可用實功率,並造成換流器電流增大、廢熱累積情形。

不過也有無上述限制的UPS,工業用不斷電系統會使用IGBT、IPM(智慧功率模組)作為換流器核心,其特性比起MOSFET換流器要有較好的表現,不過功率元件及控制電路複雜,成本高昂,家用不斷電系統並不會採用。
===
ups是從電池轉換成市電交流電,變成方波
但因為方波跟很多新式電子器材變壓器有衝突,
所以修正方波成階梯方波,稍微接近AC正弦波(通常只有多一到兩階)

因為越來越多的新式電源都是APFC(80+),方波輸入會產生使修正產生錯誤,跳電
修正方波雖然比較好,但經常會聽到翁鳴聲,因為APFC電源修正緣故

市售許多UPS到目前還是容易導致跳電後斷電問題
不是電池沒電,而是挑電瞬間APFC修正與UPS供電匹配產生問題
電腦還是會關機

最近上市一些新UPS都標榜SMART或PURE SIN(正弦波)
重點與電腦APFC電源能更完美匹配
===
Reference:
http://www.mobile01.com/topicdetail.php?f=503&t=529539&p=1&cache=0